Why Go? Use Racket - <AUTHOR> https://cxwangyi.wordpress.com/2012/07/22/why-go-use-racket/ <comment><USER2> I'm sorry you lost me after your outrageous claim that one must learn everything about the standard types of Go before one can program effectively.

You should know about how your types are passed around if you are using any language.

The example given was arrays in Go. Arrays are passed by value, but slices (pointers to arrays) are passed by reference. This is very simply described in the Effective Go reading. It's not a hard concept. I don't like you writing off Go with that example. It sounds like you made an emotional decision against the language and are grasping for logical reasons to support your already made decision.

How many people programming with Go pass arrays around? It's an easy lesson to learn.

<comment><USER3> There are many valid criticisms of go, but the one presented in this article make no sense. Or maybe only make sense if you're a huge dynamic languages fan and can't stomach static typing. Personally, as someone who used to be a huge fan of dynamic languages like Python, I've sobered up as I've grown older and had to fight with large python and JavaScript code bases. A compiler that is fast with clear error messages is tremendously valuable.

<comment><USER4> If using dynamic typing like Python's is being drunk, then at least Go is like being tipsy - not quite sober, but quite functioning.

<comment><USER5> Only if you make a habit of using reflection (you shouldn't). Otherwise it's designated driver all the way.

<comment><USER6> > Only if you make a habit of using reflection Or type switches. Or nearly > anything involving interface{}.

</comment></comment></comment></comment></comment><comment><USER7> No. Because static typing.

However much Go's type system might lack some means of expression, the type system is there, and it prevents many bugs that can easily crop up while using a dynamic language.

I'd rather say 'use OCaml' or 'use F#' or even 'use Haskell'.

<comment><USER8> Or Clojure or Erlang. Funny enough out of "functional" languages those have probably just as much (or even more) been used to develop distributed, fault tolerant systems than F# or Haskell. Just saying.

BTW both Clojure and Erlang allow a form a gradual typing.

From personal experience. I've used both static (C#, C++, Java) and dynamic typing (Python, Erlang), and have to say, the prevents-many-bugs excuse as the main problem with dynamic types just wasn't true.

Maybe my code is more complicated and dealing with distributed state, consistency, and protocols but what what kills everything is usually logic errors, network failures, files not being there, misconfiguration, segfaults, user-after-free, and the most evil ones, shared global states in a concurrent shared-heap environment.

Things like "oh I expected an int but got a string" are pretty trivial and easy discovered.

Moreover, in a recent service I implemented. I did in Python and I believe the faster development time and less code to write in general, gave me time to write better integration tests that exercises and covered the code a lot better. I would have had to write the tests anyway, even if this was written in Haskell.

Perhaps static typing helps a lot more in large code bases. Think of a large game, or a CAD application or some huge C++ back-end. But, if you buying into the whole micro-services fad, well, you shouldn't have large code bases if you can help it.

Another big motivation for types, which I think most people have in mind when they pick a strongly typed language is performance. Usually static typing and a very large performance increase would go hand in hand. Now with the effort put into v8 and PyPy we see that gap getting smaller.

<comment><USER9> > Or Clojure or Erlang. Funny enough out of "functional" languages those have > probably just as much (or even more) been used to develop distributed, fault > tolerant systems than F# or Haskell. Just saying.

(I generally agree with the gist of your comment, I think. This just stuck out.)

I don't believe Clojure belongs in that class (as "proven" for writing reliable software), but whatever.

If you want truly reliable software and have the budget, then you just need to throw _process_ at the problem -- it doesn't matter much which language you use. Several (if not all) the Mars landers were programmed in C -- with very few critical flaws experienced/discovered[2]. The Ericsson switches that achieved previously-unheard-of reliability were programmed in Erlang, but they used _process_ and a huge number of engineers to achieve that. (Plus they're mostly stateless and so can just reset if they do it fast enough and don't lose _important_ state when doing so.)

For large-scale software which _has to evolve fast_ , I belive strong type systems do win out. It's not so much that they prevent bugs which could be caught by test suites, but having a strong type system means that you can be _certain_ that there are a _lot_ of tests that you actually will never have to write or, more importantly, _rewrite_ as the system evolves.

There have been actual studies which may be of interest[1], but even if I'm on the "winning" side, I don't think I would put too much stock in the methodology/analysis of this particular study. (E.g. concluding that JavaScript suffers from few concurrency bugs relative to other languages is kind of being oblivious of the fact that JS is single-threaded (semantically) and that all the other languages in the comparison permit "real" concurrency/parallellism, and that it should thus perhaps be excluded from the category or at least treated separately.)

[1] [http://macbeth.cs.ucdavis.edu/lang_study.pdf](http://macbeth.cs.ucdavis.edu/lang_study.pdf)

[2] [https://www.usenix.org/conference/hotdep12/workshop- program/...](https://www.usenix.org/conference/hotdep12/workshop- program/presentation/holzmann)

(Sorry, references out of order because edited-post-facto)

<comment><USER10> _> If you want truly reliable software and have the budget, then you just need to throw process at the problem -- it doesn't matter much which language you use._

I also generally agree with your comment, but I have to take issue with this statement. If this were true, Ericsson wouldn't have had to abandon the AXE-N project.

Quoting from Joe Armstrong's PhD thesis[1]:

"1995: The AXE-N project was a project to build a "next generation switch" to replace the Ericsson AXE-10. This extremely large project ran from 1987-95. After the AXE-N project collapsed a decision was made to "restart" the project using Erlang. This project eventually resulted in the development of the AXD301 switch."

"During the period 1996–1997 a three-person group (myself, Magnus Fröberg and Martin Björklund) redesigned and implemented the OTP core libraries."

"1998: Ericsson delivered the first AXD301. The AXD301 is the subject of one of our case studies in Chapter 8. At the time of writing (2003) the AXD301 has over 1.7 million lines of Erlang code which probably makes it the largest system ever to be written in a functional style of programming."

[1]: [http://www.erlang.org/download/armstrong_thesis_2003.pdf](http://www.erlang.org/download/armstrong_thesis_2003.pdf)

<comment><USER9> Thanks for digging out the history. I don't think we can conclude from your excerpts that the deciding factor was Erlang. However, I accept that my statement that it was "just engineers and process" may have been exaggerated or mistaken.

<comment><USER10> The deciding factor, as always, is the ability to manage complexity. There are many ways to improve this ability, and process is certainly one of them, however, the choice of programming language is, to my mind, the most important one.

XenSource/Citrix is another great example[1]:

"In 2002, members of Cambridge University released the open source Xen project to provide free high-performance virtualization technology for the masses."

"In 2004, the team founded the company XenSource and began developing the enterprise-level distributed management software that would make virtualization easy and form the backbone of their products in the years to come. A team of thirty dedicated programmers in Palo Alto California began developing the software in C, Python and Ruby."

"Two years later, the US team had succeeded in burning tens of millions of dollars funding but had failed to produce any product. So XenSource, under new management, took the bold step of replacing their large team of US developers with a team of only four British OCaml developers. Within months, all of the Python and Ruby was replaced, both reliability and performance were dramatically improved and the company shipped their first product. One year later, XenSource sold to Citrix for $500M."

[1]: [http://ocamlnews.blogspot.co.uk/2008/11/stunning-slides- abou...](http://ocamlnews.blogspot.co.uk/2008/11/stunning-slides-about-growth- of-ocaml.html)

<comment><USER9> Indeed. I must admit that my pro-FP inner geek giggled just a little bit at this bit of "money talks".

I think it's imperative to question the "reliability and performance were dramatically improved" kinds of statements with quantitative research. It's just that this kind of research is _insanely_ hard.

(Disclosure: I'm definitely on the FP team, but I want do be able to argue _objectively_ and _quantitatively_ for the benefits of my approach.)

<comment><USER10> I fully agree. Have you seen the 1994 Hudak study[1]?

"A simplified version of real-world problem was chosen by the Naval Surface Warfare Center (NSWC). This problem, a geometric region server (geo-server) is one component of a much larger system, NSWC's AEGIS Weapons System (AWS), which NSWC is in the process of redesigning."

"The participants, each considered an expert programmer in one of the programming languages being tested, was asked to write a fully functional prototype of the geo-server, while keeping track of software development metrics such as development time and lines of code and documentation."

"The results indicate that the Haskell prototype took significantly less time to develop and was considerably more concise and easier to understand than the corresponding prototypes written in several different imperative languages, including Ada and C++."

[1]: [http://www.cs.yale.edu/publications/techreports/tr1049.pdf](http://www.cs.yale.edu/publications/techreports/tr1049.pdf)

<comment><USER9> Yes, indeed, I've read it. Unfortunately, I think we should regard the early studies (such as Hudak's) as basically preliminary and mostly not-well- founded. I know that's horribly conservative, but y'know...

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> The OP's complaint about Go's type system seems to mainly be that memory allocation is explicit.

Go is always "pass by value", and it's true that I've watched developers struggle to grasp the full ramifications of what that means regarding memory usage. But not understanding the subtlety of memory allocation usually means your programs will simply run slower and consume more memory. It does not usually mean that your programs will run incorrectly.

Given that the OP mentions that they find the slower, more expensive execution of racket programs to be an acceptable trade-off, I'm surprised that they have a problem with this.

Personally, I prefer running in a language that allows me to reason about the memory allocation explicitly. I'd only prefer to give that up in favor of a declarative language that could compute the optimal execution for me. Unfortunately that language is a bit of a unicorn for general purpose programming.

<comment><USER12> In Go you can pass a pointer, and a pointer to a pointer. I understand both cases are usually called "pass-by-reference". If you call "pass-by-value" to passing a pointer, then the notion of "pass-by-value" and "pass-by-ref" are not very useful.

<comment><USER11> If what you are passing is a pointer, then the value of the pointer (an integer) is copied. So pointers are passed by value.

"Pass by reference" means that the runtime will convert what looks like an instruction to copy a value (such as a data structure) into an instruction to copy only the address. Go has no such concept. You cannot make a new value that is a "reference" to another value. If you make a new variable that takes a value, that variable allocates a new block of memory the size of that value. Assigning a value to the variable (or passing a value to a function) makes a copy of the value into the new memory address. You can make a "reference" only by explicitly making a pointer and copying the address of another object.

"Pass by reference" languages treat everything as a pointer by default, forcing you to make a copy operation when you do not want this behavior. This may seem like an equivalent programming model, and possibly simpler because this pointer business if confusing at first. However, basic concepts such as a call stack or an array of values can no longer be expressed easily, because with "pass by reference" languages you have removed the concept of a value from the language. So pass-by-reference languages can lead to confusion in large programs, even if they seem simpler at first.

Basically, go is "pass by value" because the language forces you to always be explicit about when you are copying an entire value, and when you are only copying a pointer.

</comment></comment></comment><comment><USER13> Of the complaints you can make about Go's type system (and there are many), being too complex is not one of them.

</comment><comment><USER14> In the comments he says he changed his mind about Go, and the necessity of the efficiency gain over Racket. So there's some confusion apparently. [https://cxwangyi.wordpress.com/2012/07/22/why-go-use- racket/...](https://cxwangyi.wordpress.com/2012/07/22/why-go-use- racket/#comment-871)

</comment><comment><USER15> It's a chicken and egg problem, but the real reason for me to use Go vs Racket is that learning the former will further my career significantly, while latter won't at all. Sad, but true.

<comment><USER16> It depends. Learning Racket and the design methodology taught by Felleisen, et al. could help you become a better programmer _in general_ , and thus significantly further your career.

 _How to Design Programs, Second Edition_

[http://www.ccs.neu.edu/home/matthias/HtDP2e/](http://www.ccs.neu.edu/home/matthias/HtDP2e/)

<comment><USER15> Sure, I agree. But the impact is much less direct. Most interviews go like this: "Have you worked with Angular?". And you just don't really need to be a very good programmer to have a well-paying job.

</comment></comment></comment><comment><USER17> Author thinks Go's select statement has any resemblance to with epoll and kqueue. Didn't read further.

<comment><USER18> That's too bad, because you missed the brilliant ending to the post, in which the author answers the question posed in the title:

> P.S. As noted in [link], Racket programs build and run much slower than Go > programs.

</comment></comment><comment><USER19> I like crosscompilation and being able to deploy a stand alone executable without the whole sdk needed.Does racket do that?

<comment><USER16> Yes, that's possible:

[http://docs.racket-lang.org/raco/exe.html](http://docs.racket- lang.org/raco/exe.html)

[http://docs.racket-lang.org/raco/exe-dist.html](http://docs.racket- lang.org/raco/exe-dist.html)

<comment><USER20> I may have missed in those docs any mention of cross-compilation. The first result for 'cross compile racket' is [1]. Of course that's from 2013, so maybe it changed since then.

[1] [https://groups.google.com/forum/m/#!topic/racket- users/LLB6o...](https://groups.google.com/forum/m/#!topic/racket- users/LLB6oV1VsPo)

<comment><USER16> You're right – I keyed in on "stand-alone executable" and not the "crosscompilation" part of the question.

</comment></comment></comment></comment><comment><USER16> The blog post is a couple of years old, so it's probably worth noting that _PLaneT_ [1], mentioned by the author, has been superseded by a new _Packages_ [2] system. PLaneT is still operating, however, and libraries hosted there can be installed with raco[3].

[1] [http://planet.racket-lang.org/](http://planet.racket-lang.org/)

[2] [http://pkgs.racket-lang.org/](http://pkgs.racket-lang.org/)

[3] [http://docs.racket-lang.org/raco/index.html?q=](http://docs.racket- lang.org/raco/index.html?q=)

</comment><comment><USER21> I'll come right out and say that I _despise_ Go. It's a terrible language that ignores decades of language research and brings nothing new to the field, but has become popular due to Google hype.

That said, Go -> Racket is a pretty big jump. Even though I think Go is terrible, I can at least take the time to see the problems it's solving and offer comparable languages. I suggest Rust as a Go replacement.

Don't get me wrong, Racket is pretty good. It's not the Lisp I would pick (I really like Gambit Scheme) but it's at least a Lisp. But a high-level language like Racket isn't really comparable to Go. They're just in different spaces.

<comment><USER22> Rust's and Go's strengths are very dissimilar, there's no reason to consider one as the replacement for the other without considering a dozen other worthy languages in between.

<comment><USER21> Sure, if you make vague enough statements, they're hard to disprove, which might lead you to believe that what you said is correct even though you haven't made a provable or disprovable claim.

There are plenty of problems where one might consider using Go or Rust. The same cannot be said of Go and Racket, or Rust and Racket. I wouldn't consider using Racket for a situation where I need high performance or low memory usage --the numbers just don't work. Likewise I wouldn't look at Go or Rust for building a data-presentation type webapp.

</comment></comment></comment><comment><USER4> I'm inclined to disagree about the distinction between pointers and values being explicit, and how that is bad - I think it might be the right decision in an imperative language that tries to be performant in a straightforward way (as opposed to language that tries to be performant by relying on compiler optimizations - that might work for certain languages). It allows you to be aware and more careful about indirection and memory layout, which obviously can buy you a lot with regards to performance.

It certainly seems like the more lower-hanging fruit than what the usual advice for getting a fast programming language is - make memory management explicit/manual (though it seems that if you have pervasive manual memory management, you end up with a clear and explicit distinction between values and pointers to values anyway).

</comment><comment><USER23> shouldn't be: Why Go? (Use (Racket))

<comment><USER24> That looks like you want to use the result of Racket, rather than use Racket itself.

</comment></comment><comment><USER25> Racket's website ([http://racket-lang.org/](http://racket-lang.org/)) has an "explain" button by the code snippet. Is the existence of such a button perhaps a statement about the quality of the syntax?

<comment><USER26> No, it's a statement that the developers of Racket care about explaining how things work.

<comment><USER25> Perhaps because they need to? Or do you find Racket as clear as other languages? Even other Lispy ones?

Without trying to be insulting, I find Racket aesthetically unappealing.</comment></comment></comment>


Ask HN: Securing internet shared with neighbor - <AUTHOR> I have just moved into a new flat and while trying to get my internet connected have discovered that my flat and the neighbor's are not legally subdivided - meaning that we can only have one internet connection.
If we do end up sharing a connection how can I ensure that my traffic is kept private and that the shared connection doesn't introduce any security vulnerabilities?
My best idea so far is to split the connection into two subnets and with each having a blanket ban rejecting traffic from the other but I haven't physically implemented anything like that before and I'm not sure if it is feasible in practice. <comment><USER2> How much do you care? How much do they care? I go to lots of people's houses and they openly give me the wifi password to their network.

That said, having security is good. And building networks is fun. :)

If you are comfortable with a little Linux you could get a router and reflash with OpenWRT. Divide into 2 different VLANs. Have one port on the router connect to your VLAN and the other port connect to your neighbor's. If you use your own router on this port, you would treat this port as WAN and your own network as LAN. It would probably be NATed so your neighbor would have a harder time getting into your network. The OpenWRT GUI makes it pretty easy, but it helps to know a little about subnets and routing.

For a commercial solution, you could get a Ubiquiti Unifi gateway with a Unifi switch. Basically does the same thing. I'm not sure I would say their GUI is easier or harder than OpenWRT. You still need to know a little about networking.

If you don't sufficiently trust your neighbor having access to the WAN port, you could connect your own VPN router to your port on the VLAN.

</comment><comment><USER3> As long as you're sharing the network you'll be vulnerable on some level. One easy fix could be to setup a VPN so all of your traffic is encrypted.</comment>


Ask HN: Best practices for OS X dev environments - <AUTHOR> I'm about to get a new Mac and will be starting fresh on a new drive. I would like to know if there are any best practices in regards to creating multiple user accounts, with different permissions for my scattered development work.
I spend time with node, python, and RoR. I like cloning projects from github and taking them for a spin. I test out bitcoin projects, and send GPG emails, and ssh into multiple servers. And I do all of this on my main user account that has sudo.
Is there some best practice that I should be aware of that would have me use multiple unix users on my new Mac? <comment><USER2> I've been using Ansible + Homebrew + Vagrant/VirtualBox for the past couple years, and am now able to provision a new Mac for myself in about an hour (with all my apps and settings in place for development) with a good internet connection.

See: [https://github.com/geerlingguy/mac-dev- playbook](https://github.com/geerlingguy/mac-dev-playbook)

Once you start using VMs and/or containers for your development, you'll stop worrying about environments and breaking things :)

</comment><comment><USER3> Don't install server-side stuff directly on your Mac. If you are working on server-side projects, then use virtual machines. Vagrant in combination with a configuration management system (e.g. Puppet) is very helpful here.

Use Homebrew to install command-line tools. Use Homebrew Cask to install GUI tools that aren't on the Mac App Store.

Lots of people find it useful to check their environment's configuration files into version control – check out popular dotfiles repositories. On OS X, this also includes scripts that call `defaults write` for integration with OS X preferences.

As far as multiple unix users are concerned, just create them and use them. There's no special trick you need.

<comment><USER4> Vagrant has been a much bigger time sink for me than benefit. The ssh-agent never works while provisioning for nix servers, only during ssh (which I can do using the -- -A regardless). It often gets confused and the machines need to be destroyed and re-created after 1-2 provisioning attempts. Packers (The tool used to create vagrant boxes) lack of support for winrm on windows systems has also been a bone of contention. It requires a number of workarounds (like installing open-ssh) on the windows VM that in no way would be viable on a production windows server. And that divergence allows for the "It works on my machine" bugs which is really the whole point of using Vagrant. I use chef for provisioning, and Vagrant also downloads the chef provisioner every single provision, I suspect it does this with puppet as well, so if you're developing on the go and need to re-provision, you're either out of luck or require an unlimited data plan.

Homebrew Cask also has no oversight for breaking changes, so use this only as a convenience, not a tool to be relied upon. It frequently looses track of applications, and I can't even find where it decides to put some error logs if they're created at all.

Some of these problems could be my lack of experience in operations, but the documentation for these is far from complete. A VM with snapshots and a good backup strategy will serve you better in the short term. This changes if you're attempting to support multiple dev, but if you're a lone guy, then snapshots are far far less buggy.

<comment><USER5> > Vagrant has been a much bigger time sink for me than benefit.

This has been my experience as well... and I would really, really like to have a system in place where I could painlessly spin up VMs to do development in, so that I could leave my Mac as is.

<comment><USER6> It's called Docker.

<comment><USER4> Docker just spins up a VM on OS X with boot2docker so you don't get any real benefit here.

<comment><USER7> Yep, although it creates only one you can run a bunch of containers in it.

It feels almost as a native support, but the hack is betrayed by the networking setup.

I wish it would be possible to just expose ports on the real localhost.

<comment><USER4> Absolutely, I should have specified 'a single vm' in my response. I didn't understand that when I was first trying to understand boot2docker, and now I'm using imprecise language to help confuse others. Thanks for clarifying.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> I use vagrant + virtualbox myself and spin up development environments on the fly. It really is "the way to go". Work actually provides vmware fusion (and a license for vagrant), which also works pretty well. Fusion offers more networking options (like if you're working on pxe boot images), but I found that it's easier to track and support virtualbox images.

One thing that I've thought about trying though, is Boxen. Github supports hundreds of developer macs and they built this framework to do so. It looks pretty incredible. [https://github.com/blog/1345-introducing- boxen](https://github.com/blog/1345-introducing-boxen)

</comment><comment><USER9> I don't think you will find multiple OSX user accounts viable/enjoyable. OSX puts a lot of important preferences (keyboard/mouse settings for example) within the user account, so you will end up having a nightmare keeping things in sync and sane. You won't be able to rely on a lot of important tools like dropbox or 1password easily. Just stick with 1 user. Use docker or virtualbox/vagrant for stuff you don't want to run as your OSX user.

Here are some of my tools and tips.

\- homebrew is great \- homebrew cask is helpful, too \- 1password or similar \- virtualbox can give you clean playgrounds and test environments that match your servers \- boot2docker is handy for quickly starting and running services like databases without polluting your mac directly too much \- I also get a lot of use out of vagrant but YMMV \- I've lately started using project- specific instances of chrome (created with the chrome SSB script). This lets me keep lots of tabs separate and easily pause work and resume later \- The chrome Tabs Outliner plugin is also really key

Here's my recent blog post with more details: [http://peterlyons.com/problog/2015/02/osx-development- setup](http://peterlyons.com/problog/2015/02/osx-development-setup)

<comment><USER3> > I don't think you will find multiple OSX user accounts viable/enjoyable. OSX > puts a lot of important preferences (keyboard/mouse settings for example) > within the user account, so you will end up having a nightmare keeping > things in sync and sane.

I've used multiple user accounts for years and I found multiple user accounts very useful when there are clear separations between projects (e.g. multiple freelance clients).

The settings you refer to are the kinds of things that belong in your dotfile repo. I can set up a new account and import all my settings in a matter of seconds this way – not a nightmare at all.

> I've lately started using project-specific instances of chrome (created with > the chrome SSB script). This lets me keep lots of tabs separate and easily > pause work and resume later

This is what multiple user accounts are for, except they work with all applications, not just Chrome.

</comment></comment><comment><USER10> I use pkgin on my Mac instead of brew, but that all doesn't matter much since I do everything in VMs with Vagrant like most others here.

Definitely don't use your Mac in single-user mode though. Not that complicated to set up.

</comment><comment><USER11> I use vagrant + virtualbox (runs ubuntu via vagrant setup) + ansible to bootstrap the VM.

I've had this setup for 2 years now. No issues and I get to use sublime to edit files locally while they are shared with the VM.

<comment><USER12> I do the same, but I've had trouble with the overhead of virtual machines (admittedly on an older laptop). Have you not found this to be a problem at all?

As deployments get simpler and the usefulness of Ansible for server config declines, I'm thinking about abandoning the VMs and going back to running things in OS X.

<comment><USER13> > Have you not found this to be a problem at all?

Not myself. The VMs are never doing anything so taxing that they incur significant overhead. I can regularly keep 3-4 running concurrently without an issue.

> usefulness of Ansible for server config declines

I don't ever see this being the case. Configuration is becoming more challenging, not easier. Even if you use a tool like Docker perfectly for all of your services (which is ironically very hard without some kind of CM tool beside dockerfiles), you still have to: install packages, change configuration files, run commands, enable services, change permissions, change firewall rules, modify DB users, manage SELinux, setup log file rotation...

Servers are hard to set up and maintain in a coordinated fashion without some kind of CM tool. And while PAAS providers can handle quite a few lightweight services without requiring you to use any CM tools, there comes a point where they no longer scale the way you need them to, and you're back to provisioning VMs or even bare metal.

</comment></comment></comment><comment><USER14> Everyone is suggesting VM's but I found them far too much of a pain. Homebrew has been able to install all databases and other dependencies for me.

<comment><USER15> I really like the idea of a VM on mac OS too, but recently I've been experiencing nothing but trouble... I use to develop on a Ubuntu machine and having everything running natively, then I started to work from a co-working space, so I setup my Mac with Vagrant, Virtualbox, Ansible (for provision), to run my Django app, and after that I noticed that all my browser calls to the local development server were taking between 1 ~ 5 seconds (with tons of involuntary context switches in the debug toolbar), when they take 300 ms on my Ubuntu machine... I've heard that last Mac os has trouble with DNS, maybe that's what it is but I don't really know what to do. So as much as I like how clean it is to build a VM and separate it from the rest of your system, the overhead and the network latency is too much for me, I'll stick to installing everything with brew and virtualenv locally.

<comment><USER16> Search "Mac fix DNS" and you'll find what to do.

Here's an example: [http://arstechnica.com/apple/2015/01/why-dns-in- os-x-10-10-i...](http://arstechnica.com/apple/2015/01/why-dns-in- os-x-10-10-is-broken-and-what-you-can-do-to-fix-it/)

</comment></comment></comment><comment><USER17> Use one VM per project, not Mac OS X. Unless of course you're deploying on Mac OS X.

Use snapshots and switch between them when disk space becomes an issue.

The big advantage is that, either through careful notes or configuration management, you'll actually be able to recreate your development environment in the future.

<comment><USER4> Even if you're deploying to mac, you should use a mac vm. If you manage to get a buggy or corrupt package, it's much easier to revert to a snapshot or reprovision a vm than to reprovision your machine.

</comment></comment><comment><USER18> In regards to Python and Ruby (on Rails), have you found the tools pyenv and rbenv (or rvm)? Node also has a similar tool, nvm. These all allow you to manage separate version of languages and sets of package dependencies. I have found them invaluable in keeping concerns separated.

I lean more towards local installation for software that can handle multiple applications/connections from one install (e.g. Postgres) unless I'm preparing my staging environment. Sometimes I use Docker containers for local services (e.g. ZeroMQ) while developing so I don't incur a large overhead for every service my application requires. VMs are used for staging.

I follow this pattern on Linux and OSX.

<comment><USER19> I tend to agree. Most of my web development work lately has been with Rails, although a bit has been with Node, and a bunch in Python in the past. Rbenv is wonderful for managing different versions, npm takes care of local dependency installs quite nicely, and virtualenv solves the problem for Python too. I generally just install a local copy of postgresql and redis, and I'm good to go without having to mess with a bunch of different VMs and things like that.

</comment></comment><comment><USER20> It is interesting to see everybody using VM's and containers.

Personally I have a web server I do all my work on, so I can get to that from my mac over: http, ftp, ssh, and vnc.

I do all my work online so I can easily point any device (or ask a friend with an exotic device to click a link to test something) and I can also work from any device with an internet connection.

This setup has let me be flexible, travel, work, and get things done for the past two years. I highly recommend a dev environment thats also already online so when your laptop lid is shut, your ability to work isnt!

<comment><USER21> That's what git is for, I don't see how a webserver could replace several vagrang boxes

</comment></comment><comment><USER22> Remember, OS X is a UNIX based operating system. Most of the best practices that apply to say an operating system like Linux also apply to OS X! All my UNIX configurations are somewhat the same and this allows my workspaces to be uniform regardless of the specificity of the underlying OS (I mostly use OS X and Linux!). I think you need to tinker and find out what work environment suits you best, and its not a static situation. As you go on you will change and tweak things, thats the beauty of it all!

</comment><comment><USER23> In my opinion, learn to use boot2docker and just spin up each dev environment with its own containers as you need them. Automate everything so that you run one command to switch between projects.

</comment><comment><USER24> I installed Ubuntu as a second OS since lots of the linux open source stuff just does work much better natively than with homebrew.

For server stuff I would use docker. For docker it's the same story, linux native is better than OS-X with boot2docker.

If you need a lot IDE's then OS-X might be the better choice since retina support is not yet as good on Ubuntu. On the other hand Sublimetext is perfect on linux with retina.

</comment><comment><USER25> Is the prevailing opinion then that OS X really just isn't a good development environment? Seems like most of the suggestions so far are "install one or more Linux VMs". As someone who develops on a MacBook Pro everyday, I know I definitely fall in the Linux VM camp.

<comment><USER3> No, it doesn't matter what platform you are developing on or deploying to, if you are working on server-side stuff, use a VM.

It's not about needing tools from Linux, it's about keeping your development environment and your deployment environment separate. Otherwise all sorts of unwanted dependencies can creep in and it's difficult to reproduce the correct deployment environment outside of your development environment. If you manage your deployment correctly from the start, it's a hell of a lot easier.

For instance, if you install a web server in your case-insensitive development environment, write a load of code, then deploy to a case-sensitive deployment environment, then you may inadvertently introduce errors because you got the case wrong somewhere in your code. You introduced a dependency upon a development environment property that wasn't present in your deployment environment and things broke.

The environment you write code in and the environment you have to execute that code in are often very different things. Mixing them up is bad news – that's where virtual machines help you out by keeping the two separate.

</comment></comment><comment><USER26> Vagrant + provision.sh scripting is as simple and powerful as it gets.</comment>


Ask HN: Being a manager while programming - <AUTHOR>

Your company is in need of good managers.  Your company is in need of good programmers.  You can do both pretty well but you enjoy programming more.   Unfortunately, the place is in desperate need of a good manager.  You know if you don't become the manager, someone very bad will do it.  The other way it might happen is you could work under the good manager while your coworkers who you enjoy working with must deal with the bad one.<p>Is there any possible to do both or are you forced to choose one or the other?  Has anyone here worked under a full time manager who also writes great code at the same time? <comment><USER2> Sure, you can be a good manager and write great code at the same time. But not on the same project or company. Maybe your pet project outside of work or an open source project.

To be clear, I'm making a distinction between a great tech lead vs. a great manager. Both those roles are often confused with each other.

A tech lead will lead the project to launch by managing resources, unblocking team members, making tough decisions, writing productive code, etc.

A manager will ensure smooth operation of their team by making sure their reports are motivated, encouraged, challenged, etc. They will actively seek to recruit new team members, solve resource issues, have tough talks with underperforming reports, navigate politics and negotiate with other teams, etc.

You cannot simultaneously do both. They require very different skill sets to be good and even higher skill to be great. If you are looking to keep coding and do some of the leadership work, then being a tech lead is better for you.

</comment><comment><USER3> I don't know the size of your team or the scope of your work, but I think that it is difficult to be a good manager and a good coder while conforming to a 40 or 50 hour work week. Both positions are skills that are difficult to master and require a focused effort. When attempting to do both, it is likely that one will be done poorly or the role will eat up 80 hours of your week.

My advice- if you become a manager, look for ways that you can support your developers. Look for ways to conteibute code, but Don't expect to be the lead developer on critical functionality while also managing and coaching resources.

There's also a system of balance in the manager and developer relationship. If you are the developer and fail to meet a major milestone, who hold you accountable?

</comment><comment><USER4> I don't know about "great code", just a lot of it, but I've done this for more than 12 years (mostly because we're not really successful at hiring the kind of people we want and need - blame it on the country and our Perl ecosystem), so it can work.

My opinion is that it's doable to some extent, but not satisfactory because you'll feel like you need to be doing much more of either of these things.

</comment><comment><USER5> going through this right now. It's tough. The great managers I've worked under in the past were pretty much 100% managers. whenever they had delusions that they could pick up a small coding task, they'd end up being brought off task by managerial duties and would delay the rest of development. Obviously, different people can balance this, and every company is different.

<comment><USER6> I think you are right; and every company is really the same in this regard.</comment></comment>


US Air Force seeks private bids to launch psy satellite - <AUTHOR> http://www.reuters.com/article/2014/07/16/us-usa-military-satellite-idUSKBN0FL2RC20140716

<comment><USER2> Source headline has "spy" not "psy". Its not (officially, at least) a mind- control satellite.</comment>


The antithesis of Monsanto? - <AUTHOR> https://hack.ether.camp/#/idea/s33d <comment><USER2> The anti-thesis to Monsanto will come through a Blockchain</comment>


Ask HN: Europe Recruiters? - <AUTHOR>

All - I'm a U.S. citizen with strong tech experience looking to move to Luxembourg. Where does one find positions or recruiters for senior level positions? <comment><USER2> Have you checked out the monthly "Who is hiring?" threads here on HN? They're posted on the first of each month, and all sorts of companies post job offers. It's always a long read, but well worth it.

[https://news.ycombinator.com/submitted?id=whoishiring](https://news.ycombinator.com/submitted?id=whoishiring)

<comment><AUTHOR> Thank you.</comment></comment>


Elon Musk: Cars you can drive will eventually be outlawed - <AUTHOR> http://www.theverge.com/transportation/2015/3/17/8232187/elon-musk-human-drivers-are-dangerous

<comment><USER2> I can't help but notice that Musk is not pushing for democratization of electrical cars. He doesn't feel like a new Ford.

Self driving cars are already road legal in a number of states: [http://edition.cnn.com/2012/09/25/tech/innovation/self- drivi...](http://edition.cnn.com/2012/09/25/tech/innovation/self-driving-car- california/index.html)

There is security concern about self driving vehicles, like there is already for drone: [http://theaviationist.com/2013/11/13/heron-hacked- afghanista...](http://theaviationist.com/2013/11/13/heron-hacked-afghanistan/)

And despite having over 10 years experience fielding remote controlled/partly automated vehicle, the loss from the DOJ are mounting: [http://www.washingtonpost.com/sf/investigative/2014/06/20/wh...](http://www.washingtonpost.com/sf/investigative/2014/06/20/when- drones-fall-from-the-sky/)

The future is not all rose for self driving civilian vehicles.

</comment><comment><USER3> He hasn't spent much time between the coasts, I guess. You'll outlaw cars in this country when you pry them from Americans' cold, dead hands. The transition to driverless cars may, perhaps should, happen in the biggest cities. But in the rest of the US, it's not a technological problem so much as an identity issue.

</comment><comment> X-combinator If this actually happens we are Goners...

Reddit discussion: [http://www.reddit.com/r/Futurology/comments/2zdnyn/elon_musk...](http://www.reddit.com/r/Futurology/comments/2zdnyn/elon_musk_cars_you_can_drive_will_eventually_be/)

</comment><comment><USER4> This will take a very long time to happen but it makes sense. I love to drive my vehicle but the amount of danger present in driving is astronomical. If over 30k deaths per year can be avoided by taking away manual driving, I am all for it.

<comment><USER5> Where does the 30k figure come from? I don't see that in the article. In any case, it hardly sounds "astronomical" \- that's only about 1.1% of all US deaths in 2013, according to this CDC data <[http://www.cdc.gov/nchs/data/nvsr/nvsr64/nvsr64_02.pdf>](http://www.cdc.gov/nchs/data/nvsr/nvsr64/nvsr64_02.pdf>)

<comment><USER4> 30k comes from CDC [http://www.cdc.gov/nchs/fastats/accidental- injury.htm](http://www.cdc.gov/nchs/fastats/accidental-injury.htm) Maybe it's not astronomical but being able to get rid of 30k deaths per year should be a welcome opportunity.</comment></comment></comment>


Ask HN: Is there a modern equivalent of tinyapps.org? - <AUTHOR> I found myself searching today for a site that lists low profile desktop apps. Many of the apps on tinyapps.org are not available anymore. I'm looking for a list of low-memory, low-footprint applications that are currently available <comment><USER2> [http://suckless.org/](http://suckless.org/)

<comment><AUTHOR> Cool but it seems to be very Linux focused

</comment></comment><comment><USER3> I created [https://saasprofile.com](https://saasprofile.com) to help me find software for my need - desktop or otherwise. There are few modern desktop apps listed. I'm working on an update to allow people suit their software and redesign the ui for better search. Let me know if you have any feedbacks. Much appreciated.

<comment><USER4> Which adds further proof to my theory that all JS is bad.

First, it would display gibberish w/o JS enabled, after enabling it froze the browser for 5 seconds before continuing to load the content.

<comment><AUTHOR> have to agree. unusable for me on mobile. the dropdowns keep closing themselves. I tried to click on tags but they can't be clicked on, it loads the whole item instead. seems kind of pointless to have tags you can't click on

edit: tag issue on desktop too, not just a mobile concern

</comment></comment></comment><comment><AUTHOR> portableapps.com seems to be a good starting point, as does ninite.com, but these aren't exactly what I'm looking for</comment>


Flagsio – A Scalable Feature Management Platform – Feedback Required - <AUTHOR> https://www.flagsio.com/?src=hn <comment><AUTHOR> Hello! I have just released a new version of my upcoming SaaS landing page with a few changes on the design,copywrite and imagery. [https://www.flagsio.com/?src=hn](https://www.flagsio.com/?src=hn) I would love to hear any feedback or suggestions from you. Many thanks in advance.</comment>


Whatsapp desktop knows if my phone is on - <AUTHOR> I started using whatsapp desktop and dont fully understand how it works. After the initial pairing the desktop app can send messages on my behalf. If I turn off my phone it will stop sending messages. If I then turn on my phone but run no apps, it will continue to send messages. How does this communication work? Does iOS run something in the background? <comment><USER2> Of course iOS runs platform services in the background. Push notifications, in this example.

<comment><AUTHOR> I turned off push notifications for Whatsapp and the desktop app is still able to tell if my phone is on or not

</comment></comment><comment><AUTHOR> Note I am using a MacBook Pro and iPhone in this situation.</comment>


How to gamble if you must – the mathematics of optimal stopping - <AUTHOR> http://www.americanscientist.org/issues/id.5783,y.2009,no.2,content.true,page.1,css.print/issue.aspx <comment><USER3> Prior discussion on optimal stopping from last week, with a different less technical source. [https://news.ycombinator.com/item?id=7888215](https://news.ycombinator.com/item?id=7888215)

</comment><comment><USER4> I take issue with the method posed in the article when they discuss the method using a gaussian distribution to sometimes guess a number between the higher and the lower. The reason I take issue is because the ability to generate a useful distribution requires knowledge of what numbers I pick. A gaussian distribution is generated via a mean and standard deviation. To defeat this system, all a knowledgeable person would need to do is randomly select a mean and a small standard deviation and choose his two numbers from there. Then the probability that the guesser will choose his number R to be within the mean and standard deviation of the one you picked will be essentially zero.

To illustrate in a slightly simpler way, in order to choose your two numbers choose a random integer and the same random integer + 2 (2 to at least give the guy a chance). I could choose 1 billion and 1 billion + 2, or one and three. The chance that you would choose R to be 1 billion +1 or two, respectively, is nearly zero.

In order to get above 50% you need some sort of extra knowledge. In this case that knowledge comes from the gaussian distribution. Knowledge often affects probabilities even though they dont seem like they should. Another example of this is the Tuesday Birthday Problem [1].

[1] [http://scienceblogs.com/evolutionblog/2011/11/08/the- tuesday...](http://scienceblogs.com/evolutionblog/2011/11/08/the-tuesday- birthday-problem/)

<comment><USER5> Have you reviewed Svedlin's link in this thread to a related puzzle? (I think actually the exact same puzzle.)

[http://plus.maths.org/content/mathematical-mysteries- getting...](http://plus.maths.org/content/mathematical-mysteries-getting-most- out-life-part-1)

It's rigorous and from a slightly different approach - what do you think? Also it says that even knowledge of the guesser's exact strategy cannot defeat the solution mentioned there, even if the offering party knows the strategy exactly and is actively trying to break it.

<comment><USER4> The author of that article makes the same assumption / error that I discussed previously. The trick lies in the statement "Since n>m, f(m) - f(n) is positive and this probability is greater than a half." While this is true, f(m) - f(n) will almost always be very close to zero without additional knowledge. A key statement that illuminates the assumption in his argument is "The bigger the cheque, the more times you toss the coin and the more likely it is that it will come up tails at least once - in which case you keep the cheque rather than swapping." Built into that statement is the assumption that larger numbers are less likely than smaller ones.

<comment><USER5> I don't really understand. The argument is just that you can do something to increase the probability of guessing the bigger number from being anything other than exactly, precisely 1/2.

For example the author suggests that you first randomize which envelope you choose first.

Then you open that envelope. You then flip a coin a number of times that matches the integer in the envelope, and if comes up all heads, then you choose the other one; otherwise you stop on the first one.

Obviously if the numbers are anything other than tiny integers, e.g. if they're more htan 20 or so, then for all practical purposes it is impossible that it will come up all heads, e.g. 7,342 times in a row.

But in a rigorous, exact way, that probability is not exactly 0. The probability of that many heads is lower for 7,342,352,454,356,234,753,343 than it is for 454,356,234,753,343 (where I truncated a bunch of digits) or even for 7,342,352,454,356,234,753,342 (where I changed the trailing 3 to a 2). Therefore, you are more likely to stay on 7,342,352,454,356,234,753,343 than either of those other numbers.

This is purely academic. Clearly, the chances of flipping heads 7,342,352,454,356,234,753,343 times in a row is so, unbelievably 0 it isn't even funny. But it's not actually zero, mathematically speaking.

So essentially, you have a greater chance of swapping if the number is smaller, because there is a greater chance that you will flip all heads - <USER2> if "greater chance" just means 1 in 2^7,342,352,454,356,234,753,343 instead of 1 in 2^7,342,352,454,356,234,753,344 chance.

Do you not agree with this?

Or would you still say that it's 50:50 that you will stay on 7,342,352,454,356,234,753,343 or stay on 7,342,352,454,356,234,753,344 (I changed just the trailing 3 to a 4) even if when you draw 7,342,352,454,356,234,753,343 you change your mind 1 out of 2^7,342,352,454,356,234,753,343 times and if you draw a 7,342,352,454,356,234,753,344 you change your mind 1 out of 2^7,342,352,454,356,234,753,344 times?

Would you consider the probability "the same" of holding on each one?

Or would you agree that in this particular example it is no longer 50:50 exactly, precisely. If you agree with me that it's not technically (pedantically) the same exact probability, then I am not understanding your argument exactly.

If you just meant that "for all practical purposes" the probability is the same - then of course I agree with you whole heartedly. Do explain which one you meant!

<comment><USER4> I am coming from an information theoretic standpoint. Let me start over: imagine the number writer chooses ANY two numbers completely at random. Knowing what one number is gives NO information about the second number since they were both chosen completely randomly. Therefore, the chance that the second number is larger is equivalent to the number of larger numbers divided by the total (i.e. 50% because a constant number is infinitesimally small compared to the infinity that lies on both sides). Therefore, to suggest that the probability can be swayed one way or another has to violate an assumption that I made in this argument. The assumption that the article makes which violates my argument is the assumption that larger numbers are less likely to be chosen by the number writer than small numbers. It is that crucial piece of knowledge that allows the probability to sway from 50%. That is the whole purpose of the coin flip or the gaussian equation: to reflect that piece of knowledge in your guesses. To take the idea to the extreme, if I know that there are only two numbers then I can win 100% of the time.

In conclusion, the point is that this method doesnt work in all, or even most cases; only in cases in which you KNOW that larger numbers are less likely to be chosen than small numbers. Furthermore, how much better than 50% you can do depends completely on how well your approximation function (the gaussian function or flipping coins) accurately reflects the smaller probability of larger numbers. Now if you want to deal with people, the number of ways in which people generate random numbers is so large that I am hard pressed to believe that you can find an accurate enough approximation function that will work across the population. For example, try playing this game with your 12 year old nephew who just learned about million, billion, and googleplex and you are likely to do no better than 50%.

<comment><USER5> [http://pastebin.com/akQRtDH3](http://pastebin.com/akQRtDH3)

<comment><USER4> Your "base case" is correct, no argument there and so is your secondary example. The error comes in by looking at specifics instead of the whole. The probability of success using a strategy is the sum of (the probability of success in a case multiplied by the probability of that case) for every case. Now, since the set of integers is infinite, the sum probability of having the first number you see be less than one googleplex if the number is chosen completely at random is 0 (not just "really small" like 1/2^googleplex, so small that it is zero in the sense that lim(x->inf)1googleplex/x IS zero). Therefore the chance that you will get numbers which will lead you to have a probability over 50% is 0.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> That assertion that you can win more than half the time at "guess the higher number" sounded weird, but testable.

[http://play.golang.org/p/E1L9spOjBk](http://play.golang.org/p/E1L9spOjBk)

Cool.

<comment><USER7> A nice related puzzle involving a choice between only 2 numbers: [http://plus.maths.org/content/mathematical-mysteries- getting...](http://plus.maths.org/content/mathematical-mysteries-getting-most- out-life-part-1)

</comment></comment><comment> another-one-off For me, the fun part of articles like this is convincing myself it could never work, then re-reading the article a few times and discovering that it does.

That being said, when they talk about the marriage problem I wish they wouldn't talk about it in terms of "at most 100 candidate spouses". Not even mathematicians start life saying "I will have 100 potential partners in life".

The "marriage" problem is a strategy for selecting the best item amongst k items. The strategy for finding the best item full stop hinges on how the k items are selected. Both in marriage and hiring (the two obvious places to apply this sort of thing), where the pool is drawn from has a much bigger impact than getting the best person in the pool.

Take hiring as a better example than marriage (because with jobs it often the case that there are a known, finite number of applicants). Most of them will be people who are difficult to employ, floating around in the job market. If you wanted the real 'best', you need an aggressive poaching strategy rather than a best-in-the-pool strategy.

<comment><USER8> Different scientists approach the marriage problem in different ways:

[http://www.theatlantic.com/health/archive/2012/08/better- tha...](http://www.theatlantic.com/health/archive/2012/08/better-than-a-dog- anyhow-tireless-romantic-charles-darwin-on-the-pros-and-cons-of- marriage/261197/)

</comment></comment><comment><USER9> Has anyone tried gambler's ruin in real life? Theoretically, you have the best odds of doubling your money if you put all your money down on one hand.

Given most casino games, your odds of winning a single game is less than 50%. So lets say you encounter the best case; your odds of winning are 49%. Even then, for every game you play, you are more likely to lose money.

Probability of winning = .49

N = number of times you play

.49^N will become a smaller number as N gets bigger.

[http://en.wikipedia.org/wiki/Gambler's_ruin](http://en.wikipedia.org/wiki/Gambler's_ruin)

<comment><USER10> This is described in "the Newtonion Casino" (an amazing book about a bunch of people who build 8080 computers into their shoes to beat roulette wheels).

Roulette is rigged in such a way that the best strategy is to not play. But, after that, you take all the money you would ever play on roulette and put it on a single number.

They talk about some of the other systems. They also talk about the skill of the croupiers to throw the ball such tha they can predict roughly (enough to beat the odds) where it'll land.

</comment></comment><comment><USER11> Would the "place all your money on the first hand" apply to venture investing? ;-)</comment>


300 million year old fossilized forest discovered under coal mine in China - <AUTHOR> http://www.zmescience.com/research/studies/300-million-year-old-fossil-forest-china-906854/

<comment><USER2> It's too bad they just show a reconstructed image of what the forest looked like. I would really like to see what the fossilized remains of an _"almost perfectly preserved 298 million year-old forest"_ looks like rather than an artist's rendering.

<comment><USER3> The journal article supporting information has pictures.

[http://www.pnas.org/content/suppl/2012/02/15/1115076109.DCSu...](http://www.pnas.org/content/suppl/2012/02/15/1115076109.DCSupplemental/pnas.201115076SI.pdf)

… don't despair at the little line chart, scroll down.

<comment><USER4> When they described it as being like Pompeii my imagination might have gotten the best of me and expected too much :) Very cool photos nonetheless

</comment></comment></comment><comment><USER5> Here's the direct link to the original article in case you're interested: <http://www.pnas.org/content/early/2012/02/14/1115076109>

</comment><comment><USER6> I guess researchers dubbed it, "the whole of the article from line 10, word 7 through the end?

<comment><USER7> Ha, I know.. I couldn't tell if it is "Pompeii" or "Pompeii of the Permian period". I hate that professional articles have so many typos in them these days.

</comment></comment><comment><USER8> 300 million years...

now that's an impressive timeline</comment>


The Three Unexplained Mysteries of Taxi Tipping Behavior - <AUTHOR> http://www.businessweek.com/articles/2014-08-07/tipping-taxi-drivers-data-analysis-cant-explain-these-puzzles

<comment><USER2> As for the $30 point, that may be where a lot of flat fares go - airport for $30, for instance, is probably a common data point.

As for the rest, if we're looking at cash fares, doesn't it seem necessary to examine the most common makeups of bills that would get you to that amount? If someone has all 20s, it's easy to tip $10 on a $50 fare. Boom, done. But if it ticks over to $60, perhaps people don't want to break that fourth bill, or maybe they don't carry more than 3 20s, so rather than pull out the card they just leave no tip, like a jerk.

But I don't get why cash versus card was not broken out here. Surely tipping habits differ greatly, or at least significantly, between the two methods. Why a card user doesn't tip at $60 is likely to be different to why a cash user doesn't.

<comment><USER3> You answered that a lot more succinctly than I would have. Credit vs. cash really is different.

It doesn't hurt that most of the time I'm in NYC, the taxi drivers "have broken credit card machines" or ask me if I can use cash to save them from the processing fees. Usually the currency in play is $20s and it's easier to just round up then calculate and fumble around for change and small bills.

For big fares, credit is just easier to deal with than a wad of money. The cabs all have touch screens for selecting the tip, I suspect there's some kind of psychology on that tip selection screen which explains the ending 5 and 0 fare tip dips.

And as for anything, as the price goes up, the tip goes down. If I go to Olive Garden with my wife and spent $30, I give them a $6 tip, because the waiter was nice, asked me how everything was and my water stayed topped off.

When I go to Per Se's or Le Bernardin's and drop $300 on a prix-fixe dinner, do I really want to tip them $60 because I got near enough the same service (but it involved 4 people) but they kept my wine glass topped off all night? No, but I might give them $50 because that's a nice number, is more than 15% (so I can make sure I can come back).

<comment><USER2> Yeah it's funny how much I overthink these things myself. I would really rather everyone was earning a good wage and tipping was an actual gratuity rather than a requirement to let the barista make rent. Leaving 15p in change at the bar in the UK, as I understand it, is a totally normal and friendly thing to do, but no one will think ill of you if you take it, either.

</comment></comment></comment><comment><USER4> It'd be interesting looking at histograms rather than averages and separating out cash from credit card tips.

Most taxi rides, I'm paying cash because I don't want to be bitched out by the taxi driver about using a credit card. With cash, I'm more concerned about minimizing the amount of change so I'll usually do something like hand them a 20 and say "can I get 3/4/5 dollars back".

That could partially explain some of the weird shapes in the data.

</comment><comment><USER5> I'm forced to wonder which results are statistically significant.

Yet another hypothesis for tips going up in the $20 to $30 range is because for fares over $20, riders may switch to credit card payment where the fare has a clear paper-trail, while tips for fares under $20 are underreported because riders want to get rid of their singles.

My conclusion for the results of the study is that rider sympathy for the poor medallion owners of the world varies based on the fare.</comment>


Uber's Self-Driving Cars Debut in Pittsburgh - <AUTHOR> http://www.wsj.com/articles/inside-ubers-new-self-driving-cars-in-pittsburgh-1473847202 <comment><USER2> Interesting. I did some write-up about self-driving cars and the near future is going to look like: [http://fullstack.info/autonomous-cars-letter-future- self/](http://fullstack.info/autonomous-cars-letter-future-self/)</comment>


Researchers Say WSJ's WikiLeaks Copycat Is Full Of Holes - <AUTHOR> http://blogs.forbes.com/andygreenberg/2011/05/05/researchers-say-wsjs-wikileaks-copycat-is-full-of-holes/

<comment><USER2> "We reserve the right to disclose any information about you to law enforcement authorities or to a requesting third party, without notice, in order to comply with any applicable laws and/or requests under legal process"

Would anybody here trust the WSJ to leak the documents they send and not the identity of the leaker? I have no faith.

</comment><comment><USER3> I find the idea of a single newspaper hosting a site like WikiLeaks themselves very strange. If the WSJ receives confidential information that is of value but not on a topic they typically write about will the information still see the light of day? The great thing about 3rd party sites like WikiLeaks is that they provide the information and you decide if it's valuable or not.

I have to say that I'm not sure why I would submit info to SafeHouse instead of just posting it online myself with an anonymous blog.

<comment><USER4> Only a fraction of what WikiLeaks receives is ever published, if my understanding is correct. Even look at cablegate: Only a fraction of all cables have been released.

</comment></comment><comment><USER5> Giving credit where credit is due, HN readers figured out the problems with WSJ's submission policies as soon as news of the site hit HN.

See this:

<http://news.ycombinator.com/item?id=2518060>

</comment><comment><USER6> I'd love to work with them to make a purely automated provably-anonymous file dropoff system, which could then be used by others. The type III remailer network sort of facilitates this, but there are better ways.</comment>


Defer ALL The Things - <AUTHOR> http://davidwalsh.name/deferred

<comment><USER2> Callbacks are the new _goto_ s</comment>


How we structure our work and teams at Basecamp - <AUTHOR> https://m.signalvnoise.com/how-we-set-up-our-work-cbce3d3d9cae#.lvp8eimw3 <comment><USER2> Fantastic article. I find the idea of cycles being pretty core to this. Jason mentioned it in more detail in a comment below, but the fact a stakeholder can't sway an ongoing project until its cycle is finished is huge.

I work on a small team building IT and IS infrastructure for a very sales- oriented business. Stakeholders are always throwing in a new twist at what feels like the most inopportune times. If we could tell them we'll consider it on the next formalized cycle that would be huge for preventing redirections. Stakeholders may not acknowledge it themselves, but they care less about what gets done and more about when. Closing that feedback loop we always be more effective than feature creeping a project into oblivion.

</comment><comment><USER3> The concept of large and small pieces of work, and having developers rotate between them in naturally forming teams I found to be excellent for morale and hence productivity.

Also once a cycle is locked in, it's _rarely_ adjusted. And no timesheets.

Really basic things that IMO Basecamp is doing a great job advocating for in an industry that still needs it.

</comment><comment><USER4> It's strange to me that all projects have a designer and the designer leads the project management.

<comment><USER5> Why? Design (in the ideal) is about making things actually achieve the outcome they are supposed to. It subsumes all other product work.

</comment></comment><comment><USER6> Ever since Getting Real ([https://gettingreal.37signals.com/](https://gettingreal.37signals.com/)) I've agreed with practically everything Jason Fried has ever said. Wish there were more CEOs like him.

</comment><comment><USER7> Is it 2005 again?

Someone please remind me how Basecamp is relevant?

It's a closed system that doesn't play nicely integrating with anything else... near as I know still doesn't have a Kanban board... or file versions... and search is still pretty terrifying.

<comment><USER8> I found the article to be an interesting look into an approach to project management at a small, successful software product shop.

You may not find Basecamp relevant, but they still offer a service that people pay for 10+ years after they started. How many of the Kanban board-based project management tools that exist today will still be around in 10 years?

<comment><USER7> Their strategy...

TL;DR: They dig in like ticks with marketing folks and saddle everyone else with dated and inefficient tools. The make integrations next to impossible, exports messy, and seemingly strive to fracture teams by providing duplicate services to tools like Slack, Asana, JIRA, GitHub... etc... that all do everything Basecamp does, but better, AND also offer integrations so all your teams can play nice and work seamlessly. Basecamp is cancer. I'd be surprised if they're still around in 10 years if they don't open their platform up and make it easy to swap components in and out of their closed system.

If a team already has Slack, or Skype, or Flowdock, or HipChat, or Fleep... or any of the other 200 chat tools... now with one instance of Basecamp introduce to a team they also have to check that system for messages from the one team that uses Basecamp in their company. Not even sure you can turn that feature off... but it's inefficient to not have integrations. "One-solution-fits-all" is dead, open APIs and modular tools lead to happy teams.

<comment><USER9> Do you consider yourself to be an empathic person, able to understand their needs? I sincerely hope not. The inability of tech-focused people like yourself to understand that the group of people really give a ____about the latest tools is astounding.

While there are thousands of companies who want an open, modular system, there are tens of thousands more who could care less about what an 'API' is, what an 'integration' is, or getting fancy SAAS tool A to work with fancy SAAS tool B.

These companies only care about how a tool can help them run a better business, and for that, they're going to look for a single solution that does everything they want. They absolutely will _not_ be looking for 5 tools they can string together to make some Frankenstein 'solution'. And hat's off to them for that, the sooner they realize their business is not a special snowflake the better.

<comment><USER7> Through contracting, I've been exposed to just about every tool, and combination of tools out there over the last 20+ year as a project / product manager.

Basecamp is cancer. There isn't a team around that wouldn't be better off on Asana, or GitHub + ZenHub, or Atlasssian, or Trello... or anything else.

Would gladly dedicate 5 hours per week in training people on alternatives for free, if it meant I never had to go into a client's office who used Basecamp. The amount of busy work and slop and inefficiency it allows... I get people are blind to better options, but seriously spent a few hours researching and trying the tools. A stitch in time saves nine... measure twice, cut once...

Please compare it to using other tools and see for yourself.

<comment><USER10> >>> The amount of busy work and slop and inefficiency it allows...

(Disclaimer: I've not used it in a business setting, but do roughly know my way around because we have a "family Basecamp" for some projects)

Have you considered the possibility that something that allows for a bit of "slop and inefficiency" might make for a more pleasant, and perhaps even a more productive, working environment than neo-Taylorist perfection does? I'm not actually 100% sold on the product myself, but the way it's pitched (e.g. "Work can wait") is pretty refreshing in the contemporary marketplace.</comment></comment></comment></comment></comment></comment>


Ask HN: Recommendation for outsourcing of a small SaaS MVP - <AUTHOR> Hello, I am from Bulgaria and after organizing  ofa startup around SaaS based product. It will be SPA web app MVP, with on .net core backend and angular 6 for the frontend. I need to focus on the bussiness endeavours while the base for the product is being built rather developing it by myself. On the other side the developer costs locally grew to absolute heights and I am unable to afford doing it locally. This was came to the idea of splittting the non tricky web implementation that is requiring more work and outsource it to cheaper locations, while me and other founders around doing ML work on the backend and securing the clients.
Do you think it is a good idea?
What regions and websites you would advice on for getting a freelance team to do it? <comment><USER2> As a freelancer from China who is starting my own agency, I've developed many outsourced projects for my clients, or my clients' clients. Here's my advice.

0\. Sometimes it takes MORE time and effort if you outsource it. It might take as long to find candidates and describe your requirements as if you build it yourself. And you might choose an incompetent freelancer/company and have to restart the search again. I feel it's only worth the effort to find a good developer if you plan to work with him for more than just several months.

1\. Try to get a referral. It's way easier to find a reliable developer this way.

2\. Avoid popular freelance marketplaces like Upwork. The competition tends to drive away non-desperate developers (like me).

3\. Be as specific as possible in describing what you want to build, provide a mockup if possible. Especially if you won't meet the developer IRL.

4\. Find someone who speaks English and communicates proactively, who reports progresses and delays without you asking. It'll drive you nuts if you don't know if a deadline will be met and your developer won't reply to your email.

Finally, you can send me an email if you're interested in having my company build your MVP for you.

<comment><AUTHOR> 0\. I was thinking to do very detailed specifications and have trial for a week. I believe there is no other way. Also during this week I could see how the base tasks will be performed and if it fails could cancel the relationship.

2\. That is indeed very useful advice, if I could get referral. Unfortunately I could get those from the websites I could find the agencies or people. Do you think I could rely on these?

3\. Useful advice, but what other places you would suggest. Here is good resource I found but any of these look main stream: [https://www.forbes.com/sites/abdullahimuhammed/2017/06/16/79...](https://www.forbes.com/sites/abdullahimuhammed/2017/06/16/79-websites- to-get-freelance-jobs-fast/#3a202bbf1688)

4\. Ideally I am looking for 2-4 people for 2-4 months. Then it makes perfect sense for someone on the team to be used for the communication.

I would definitely check with you once I prepare the specifications (in next month or so).

Thank you very much for the input!

</comment></comment><comment><USER3> you might want to check out bubble.is

you might be able to build a basic MVP quickly. It seemed as easy to build as you would need to put into a spec for outsourcing.

<comment><AUTHOR> I want the state of the code to be in managable state after the MVP delivery, as me and the team will need to enhance it in future.</comment></comment>


Marketing Tricks for Web 2.0 - <AUTHOR> http://www.nivi.com/blog/topic/marketing/ <comment><USER2> "Hold some features back in your first release.

Release them next week or next month. This makes your customers think that you are actively developing your product and that there is momentum behind your product."

This statement really irks me, not just as a programmer, but as a consumer. I initially thought the article might be a little joke, but since the other tips were more reasonable, I have to assume that it is serious. I can understand holding back features in your initial release, but there are much better reasons than those that were cited. To purposely trick your potential users seems to me to be a bad business model, and smells of the corporate mindset of money and growth over all else. I think it is important to remember that the whole point of developing a product is to fulfill a need (or want) of the customer, and I think that as the average consumer gets more intelligent, these types of tactics will be more transparent and will do more harm than good to the startup.

As for better reasons for holding back features:

1\. In any interesting piece of software, I would imagine that there are potentially hundreds of features which could be added. The difficult problem is deciding when to be (temporarily) content with what you have and release. Thus, some desired features must be left out in order to avoid the perfectionist mindset, where nothing ever gets released.

2\. A mostly-implemented feature may work correctly most of the time, but fail mysteriously at other times. Even with a beta release, it's probably best to avoid these types of features which only serve to make your product less reliable.

3\. A feature may be fully-implemented, but there may be no clear way to integrate it into the UI. In this case, it would probably be best to hold off and drop hints of the feature to beta testers, who could give their feedback on how best to integrate it. After all, the feature is meant for the users to actually use, isn't it?

4\. A feature may add computational complexity to the software which may be overly taxing on the initial hardware that a startup company is using. Improve the hardware before adding the feature, or better yet, improve the code which implements the feature.

Am I being overly idealistic? Am I alone in thinking that the proposed "marketing trick" is a bad idea?</comment>


Lowell Heddings Is Very Bad at Coding. Your Job Is to Replace Him - <AUTHOR> https://stackoverflow.com/jobs/133609/lowell-heddings-is-very-bad-at-coding-your-job-how-to-geek <comment><USER2> While the job ad is refreshingly candid I'm suspicious that you'll attract the right type of candidates.

It has "challenging" written all over it, but probably also "run away as fast as you can" for a candidate with the right type of experience. YMMV of course but, speaking for myself, I once accepted a similar job and rapidly put the experience to an end. The technical debt was such that refactoring anything (I was alone) while needing to add more features on a day to day basis, all while avoid booby traps in a mostly untestable code base, was far too much to overcome. If your code base is in a state anything close to what I encountered then, you likely need a seasoned CTO or engineer lead, and _several_ developers to successfully overcome the challenge.

Best luck though.</comment>


Vatican Research Observatory - <AUTHOR> http://www.vaticanobservatory.va/content/specolavaticana/en.html <comment><USER2> I was going to say tha they must have one hell of a light pollution headache, but apparently the observatory is not in Rome, but some 15km out of it in a place called Castel Gandolfo... which is actually a pretty badass name if you think about it :)

[https://en.wikipedia.org/wiki/Castel_Gandolfo](https://en.wikipedia.org/wiki/Castel_Gandolfo)

<comment><USER3> You were quite right actually, as you can see below. Castel Gandolfo is the site of the observatory for historical reasons only; light pollution from Rome is pretty strong there - and probably rising.

[http://www.lightpollutionmap.info/#zoom=14&lat=5122707.20753...](http://www.lightpollutionmap.info/#zoom=14&lat=5122707.20753&lon=1408369.13808&layers=B0TFFFFTT)

</comment></comment><comment><USER4> This is cool, but... Why? I don't mean that to be snarky, but I'm actually genuinely curious why the Vatican operates an observatory. It just seems really antithetical to Catholicism.</comment>