What are the best ways to analyze a market? - <AUTHOR>

Before you try to venture into a market with your idea to bring something better and greater how would you make sure if that idea is going to fly within the target market segment or would bring in some $$$$$$? Any pointers? <comment><USER2> Try to find a potential customer and try to sell them.

If you can make the pre-sale with 1 and 1, then you have a chance.</comment>


How to Track Six Key Metrics for Your Web App - <AUTHOR> http://thinkvitamin.com/web-apps/how-to-track-six-key-metrics-for-your-web-app/ Identified and defined the six key metrics you need to measure for your recurring revenue web app. Also shared an example Google Spreadsheet which can be downloaded and modified for your app. <comment><USER2> Your spreadsheet looks pretty cool. I think though that you could really do with a little more explanation about _why_ it's doing some of the things it's doing.

Take, for example, Customer Acquisition Cost Ratio (CACR) for the 2nd quarter (cell [H33])

Going by the formula that's:

      [H33] = CACR for 2nd Quarter =
      (
        ([CMRR for June] - [CMRR for prev March])
        * 4
        * ( [Gross profit for Q2] / [Total CMRR for Q2] )
      )
      / [Marketing costs for Q1]

Why do we only use the numbers for March and June? What is that magic 4? Why are we dividing by the previous quarter's marketing?

Your post is your chance to explain why you are right and why we should trust your spreadsheet. Don't just wave your hands and say "it's complicated".

<comment><AUTHOR> Appreciate the feedback. I learned how to calculate those numbers from Bessemer Ventures PDF, which I linked to in the article. Essentially you're taking the difference in CMRR for the quarter and annualizing it, then dividing by the marketing cost for the previous quarter.

</comment></comment><comment><USER3> This is going to be extremely useful for me. I know the basics (churn, CMMR, etc.) but I'm missing some of the others.

I'm not quite sure I understand why CPA is so simple. Right now I'm not spending a dime on advertising so I'm not spending anything to acquire these users (it's WOM and SEO). Once I start advertising shouldn't that calculation go against customers customers acquired through my advertising efforts instead of all new users?

<comment><AUTHOR> Marketing costs are only directly related to the new customers you acquire the same month (or sometimes the following month - as long as you're consistent). This isn't always strictly correct, but it should give you a good average CPA value.

</comment></comment><comment><USER4> I'm in the tricky situation of not having enough users within BitBuffet.com to really gauge these numbers accurately. I'm currently paying about 8 months of customer revenue to pull in a new paying customer, but honestly, that number isn't reliable.

</comment><comment><USER5> How much "throughput" do you need before stats like this start to mean anything? For example, if you only acquire 5 new users per month, can you really calculate a meaningful churn rate?

<comment><AUTHOR> If you only acquire five new users a month, then something is seriously wrong.</comment></comment>


Embrace Go – A modern programming language - <AUTHOR> https://developer.washingtonpost.com/pb/blog/post/2016/04/06/embrace-go/?utm_content=educational&utm_campaign=2016-04-14&utm_source=email-sendgrid&utm_term=710121&utm_medium=642102 <comment><USER2> > Java 1.0 was released in 1995 and we haven't had the need for another > general-purpose programming language ever since.

Riiiiiiight...

<comment><USER3> I could not imagine that statement being anything but sarcasm, dryly delivered.</comment></comment>


How a Startup Accelerator Changed Our Lives - <AUTHOR> http://onstartups.com/tabid/3339/bid/64027/From-Nashville-to-Boston-How-A-Startup-Accelerator-Changed-Our-Lives.aspx

<comment><USER2> My favorite subtle detail is that the picture in the middle of the post actually shows where Help Scout was seated during the program!</comment>


Ask HN: How many of you have military experience? - <AUTHOR> If so, how strongly do you identify with that identity even after your service? <comment><USER3> I don't think you're including current/former defense contractors or those that have worked in military research labs in contractor or civilian roles here, but I believe you'll find a decent amount of those on HN.

In any case, just to add a data point, after working as a defense contractor, a lot of that culture has stuck with me years later especially in terms of security consciousness and inadvertently leaking information signals, especially in this era of more and more publicly accessible social media content.

</comment><comment><USER4> I was a musician(tuba) in the Royal Swedish Army Band for two years. So not really military, but we did received thorough combat training.

I really enjoyed it, and it gave me really good experiences and taught me some valuable lessons. Our CO always said "You can do ten times as much as you think you can do and twice as much as we think you can do". The lesson is that when you've done X amount of work you usually feel that you can do X more work.

We spent a couple of weeks in the field training and that has taught me to appreciate comfort without needing it. Whenever I'm cold, hungry or tired I can always think: "I've had it much worse, this is nothing".

But still, I don't feel like a military man and don't identify much with it. It's just a valuable experience.

edit: thought -> taught

</comment><comment><USER5> I was in the US Army as linguist. While I've been out long enough that I no longer feel like or identify as a soldier, I find I very much cherish the sense of support I always felt while in the Service. I felt as though whatever came, I'd have people around me that had my back. Civilian life doesn't seem to have that. It seems an ultimately selfish culture. No tribe.

<comment><AUTHOR> Well said! Have you tried communities like www.rallypoint.com to keep in touch with your tribe?

</comment></comment><comment><USER6> I was in armoured reconnaissance. I'm glad I did it and there are times that I miss it. I still have some very close friends that I served with. However, it isn't really a big part of my life now. Obviously my trade doesn't directly apply to writing software but I learned a lot of lessons that I still use regularly.

</comment><comment><USER7> I was in the US Navy on a fast-attack submarine. As a submariner, we all have a very strong brotherhood/sisterhood due to the intense conditions and rigorous training we go through to become submarine qualified, and so in that regard I identify with my military service very much.

</comment><comment><USER8> I am a former U.S. Marine and I have found that the things you learn and the training you experience only give a glimpse of how strong the bonds you gain are in service. I will always identify with my service as there is a implicit understanding in the phrase semper fidelis, which is the Marine Corps motto. But I think that many other service members hold the same value in their service.

</comment><comment><USER9> Current military here. Starting the process of resigning and will be out in around a year. I've gotten some great training, but after ten years, the job is becoming a PowerPoint and briefing hell. My masters is in CS with a focus in machine learning, so I'll be trying to find a position leveraging that or my work in network security.

<comment><AUTHOR> Thats awesome, looks like you've set yourself up with an easy transition! Best of luck.

</comment></comment><comment><USER10> USMC 0844/0803

CWO2 retired

Being in the Marine Corps is one of the hardest, craziest, challenging, worst, miserable job I have ever had. But I wouldn't change a thing.

Semper Fi

</comment><comment><USER11> I was 8 months in mandatory Austrian service, doing lots of sports and arts and driving around in the country.

I liked it, but identification: 0

</comment><comment><USER12> USN - USS Boxer - 2003 - <USER2>

Specific 'core values' remain important to me.</comment>


Migrate Your AWS Node.js Lambda Functions to Kubernetes - <AUTHOR> https://sysadmins.co.za/migrate-your-aws-node-js-lambda-function-to-openfaas/ <comment><USER2> Why?

<comment><USER3> One example is that a client that doesn't want you to use AWS for their traffic and you need a way to port your Lambda functions to a solution acceptable to their legal department.</comment></comment>


Shattering News: How Chromothripsis Cured a Rare Disease - <AUTHOR> http://directorsblog.nih.gov/2015/03/05/shattering-news-how-chromothripsis-cured-a-rare-disease/

<comment><USER2> 60 cases in 50 years, spontaneous remission because of a totally random breakage and reassembly of the at-fault damaged chromosome... ...wild!

To quote Jack Aubrey, 1805ish, "what a fascintating modern age we live in".</comment>


Bitfloor shuts down - <AUTHOR> https://bitfloor.com/ <comment><USER2> I have a IngDirect (now CapitalOne360) checking account, which for many years was attached to Paypal and Google Checkout for receiving payments for Bingo Card Creator. One day, I got a call from their fraud/security department. Paraphrasing: "We know you're clean and well-established with us, but this use of the account with two incoming transfers a day is outside of our risk parameters, so you've got 30 days to move off it for your business use. We don't want this business."

It's highly likely that Bitfloor was receiving many times that volume from many more payers with less history and, let me be charitable here, less ability to convince the fraud department that there was a legitimate business causing the deposits. It was obvious they were going to be shut down.

P.S. If any of you think this won't happen to Mt. Gox I encourage you to consider "How high do I rate my understanding of risk controls and regulation at Japanese commercial banks?"

<comment><USER3> Can you elaborate on why incoming transfers from reputable companies have a certain risk attached? I simply can't think of any reason why that should be the case. Isn't the primary function of the bank to receive and store your money?

<comment><USER2> It could be as simple as "We do not have sufficient risk controls _on that product_ to feel comfortable with you moving that velocity of money through it. Given that your use of the product is not very valuable for us, we decline to bear an unknown, uncontrolled risk to secure your business."

</comment></comment></comment><comment><USER4> I just placed money into my account a day or two ago, and have been waiting for bitcoin prices to stabilize. So I have USD in there and no way to convert it and get it out without giving them my gov. id. and bank routing numbers. I've only accessed Bitfloor via Tor to keep my anonymity. So fuck that (the id and bank details part).

If I'm lucky, maybe they'll offer to convert funds to BTC and send them to an address.

<comment><USER5> You know what they say about poor decisions. They're made every day.

<comment><USER6> What a tremendously helpful comment. Do you have anything to contribute, instead of just poking the poster?

<comment><USER7> Actually if his comment causes the poster to reflect on the fact that perhaps this was a mistake in the first place and a lesson to be learned, the poster and anyone reading this thread might be better off.

</comment></comment></comment></comment><comment><USER8> They were a US corporation with a US bank account and registered with FinCEN. What could be the reason their bank account was closed? Overly-cautious risk department at their choice of bank?

<comment><USER9> My guess? They had two avenues to get local cash into the system, CapitalOne P2P and Bank of America (LocalTill, LLC). By taking cash, LocalTill, LLC would be required to be registered as a money transmitter in NY State (as well as the token FinCEN registration). They almost definitely were not, so once identified or threatened, they probably closed up shop, closing off that route of funds. If the exchange's bank account was also with BoA, they could have easily identified that and decided they didn't want to be a part and would close it. Something similar could have happened at CapitalOne if the P2P TOS were being violated in some way.

edit: For those that don't know how LocalTill operates -- The merchant would forward a "deposit" to LocalTill and one would be instructed to deposit a dollar amount plus a processing fee with a unique # of cents to LocalTill's BoA bank account. Upon electronic notification that the amount was received, LocalTill would send the money minus their fee on to the business which set up the transaction.

</comment></comment><comment><USER10> What's Bitfloor? I've never heard of them.

This is an ongoing phenomenon. The first time I (and I presume others) seem to hear about a company is when they're closing up shop.

<comment><USER11> Never heard of them either but if you click About you see this:

Bitfloor, Inc. is a New York City based online exchange. We run a marketplace for Bitcoin buyers and sellers. We also focus on spreading all that is great about Bitcoin and helping people purchase and use their coins with ease.

<comment><USER10> Thanks.

I wish they'd say why they're closing down. I don't love others' failures, but I sure do love learning from them when they happen. A postmortem would have made an interesting submission; a five sentence _au revoir_ from an otherwise unknown company, not so much.

I don't quite understand why this is grabbing the attention it is; this isn't like a well known company such as 37 Signals is abruptly saying pip pip cheerio. (Having said that, at least they'd write an interesting goodbye note.)

<comment><USER12> I think they said why: one of their key bank accounts is being closed against their wishes. It's not easy to get an account like that opened, and when it's closed the money has to go somewhere. In this case, back to the clients.

<comment><USER10> Bank accounts can be closed for all kinds of reasons. They don't really say what happened or _why_ their account is being closed, or why they aren't being tough cookies and working around this blip, if possible, etc.

In essence, their post is about as content-free as imaginable, which is a shame because it was a good opportunity to educate others.

<comment><USER12> They're probably too busy trying to return all the client funds to write a beautiful blog post about what happened (or rather, is happening right now). Bitfloor is active on Twitter--it might be better to tweet at them on the weekend to say you're interested in a follow-up post (mortem).

</comment></comment></comment></comment></comment></comment><comment><USER13> I just yesterday wired Bitfloor over $1000, and they have yet to acknowledge my transaction. The money is gone from my bank and is currently in limbo.

I'm frustrated that they have given so little information out, my recent transaction represents 100% of my disposable income. Perhaps part of the fault is mine, but I thought they were reputable and no warning was given. They are also no longer accepting deposits or acknowledging any in progress deposits.

<comment><USER14> Can I ask why you moved 100% of your disposable income to an account at any Bitcoin exchange?

<comment><USER15> Can I ask why you'd ask?

<comment><USER14> Because that's a surprising decision to make, whether or not it's a good one, and I'm interested in why someone would decide that.

<comment><USER16> It's probably not the first time someone has put all their disposable income into what they think is a time-sensitive investment opportunity.

<comment><USER17> Yes its not the first time someone had last money on "time sensitive investment opportunities" aka gambling. And yes there are lots of people who do that with 100% of their disposable income. They also usually lose it all.

<comment><USER16> >gambling

What makes it gambling rather than an investment?

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> They had their servers compromised last year:

<https://bitcointalk.org/index.php?topic=105818.0>

<comment><USER19> Did they ever manage to pay out the funds users had on the site at the time? Last I heard, they'd decided to solve the problem by freezing all those funds and gradually releasing them as they earned enough money on trading fees to actually repay people.

<comment><USER20> It is a little ironic consider one of the often trumpeted benefits of Bitcoin is a limited money supply and lack of a fractional reserve system. The truth of the matter is that Bitfloor was under no restrictions whatsoever on how much USD/Bitcoin it needed to have on hand in the event of something like this.

<comment><USER12> The theft from Bitfloor was roughly half the total assets (most of the BTC, none of the USD) at the time. A fractional reserve of 50% is still many times higher than what you'll find if you look in the vault of any regular bank in the US.

<comment><USER20> That might be true, but the fact is that Bitfloor wasn't required to have anything on hand. Their reserve might have been 50% in that instance, but customers are putting their faith in Bitfloor to responsibly set and maintain a reasonable reserve rate. I find it ironic that people who distrust their local banks and government to that extent will put that much faith into a Bitcoin exchange.

<comment><USER21> On the other hand if bitfloor had no reserves you couldn't steal from them.

</comment></comment></comment></comment></comment></comment><comment><USER22> Well, shit. Time to trash my bitfloor/mtgox arbitrage bot.

<comment><USER23> How do you do arbitrage when you can't short and can't move funds easily and quickly?

<comment><USER24> Say you have $1000 and 20 bitcoins of capital to work with, and the current price of bitcoins is $50 on both exchanges. Put $500 cash and 10 bitcoins on each of the two exchanges. Then if the price rises to $55 on exchange A but doesn't move on exchange B, you can buy 10 more bitcoins on B and sell your 10 bitcoins on A for $550, you now have a balance of $1050 at A and 20 bitcoins at B. Since you started out with 20 bitcoins and $1000, and ended up with 20 bitcoins and $1050, you made $50 profit.

You can only participate in trades in the other direction (buying bitcoins on A, selling on B) until and unless you can move the cash and bitcoins between the exchanges, which may take hours or days.

Of course, there are a lot of assumptions built into these numbers: The numbers assume your trading is sufficiently small compared to the total market size that your operations won't change prices, and the exchanges and blockchain charge you no transaction fees. These aren't absolutely true in practice, of course, with the consequence that prices can deviate a little between exchanges without creating an arbitrage opportunity.

Shorting would make things easier, because then you wouldn't have to keep the coins in your account at A in order to sell them, you could borrow them on demand, sell them, and then transfer from B or your wallet at leisure.

Likewise, being able to move funds quickly would help you out by reducing the time when half of your capital is out of the game because you're moving it around (I'm assuming you'll transfer 10 bitcoins to A and $500 to B after you did the trade to get back to the original situation), and the other half is half-useless because it can only be used to trade in one direction.

But neither of these features is necessary to allow you to make guaranteed profits when (or if) sufficiently large price differences appear.

<comment><USER22> Spot on. Moving BTC between exchanges is a 30minute process. With sufficient cash in both accounts it wouldn't have been an issue.

<comment><USER24> > With sufficient cash in both accounts it wouldn't have been an issue.

Depends on your definition of "sufficient." If you're no longer small compared to the market, i.e. you have enough money that a small fraction of your capital can completely fill the arbitrage-able offers and move prices back into line, in that situation moving money between exchanges is no longer an issue.

But you don't need to be that big to merely make a risk-free profit when the right kind of pricing anomaly appears. And if there are enough small actors doing this, their combined efforts can stamp out pricing anomalies just as effectively as a single large actor.

</comment></comment></comment></comment></comment><comment><USER25> I had some $ and a couple BTC in my account there, I initiated the transfer out, got my BTC right away, hopefully the ACH goes through quickly also.

</comment><comment><USER26> I wonder if MtGox is re-evaluating their move to the US.

<comment><USER27> Any exchange company should operate in one of the well-known havens like Gibraltar or Curaçao, not the US.

<comment><USER28> Anywhere but the US

<comment><USER29> or china for that matter

</comment></comment></comment></comment><comment><USER30> That's disappointing. I really like Bitfloor, I like the approach they'd taken to their API, and I felt among the major(ish) exchanges they were refreshingly open and honest. When they were compromised earlier they seemed to make a real effort to ensure all their users were taken care of, which is a nice change from the many other exchanges who just packed up shop and never paid out.

Sorry to hear the bad news, guys.</comment>


Git tips to stop you getting fired - <AUTHOR> http://blog.apiaxle.com/post/handy-git-tips-to-stop-you-getting-fired/ <comment><USER2> If you're in danger of getting fired over a commit mistake, you have more and bigger problems than this article can fix.

These are good tips, nonetheless.

<comment><USER3> There is a bigger chance of getting fired for ordering 10x the amount of food for the team, while they are crunching...

</comment></comment><comment><USER4> Out of curiosity, do a lot of people use CLI git?

I personally am much happier losing a little functionality (and all these fancy flags) for a much clearer visual interface - I'm using GitExtensions btw.

Am I alone on this?

<comment><USER5> Not alone, certainly, but almost certainly in the minority. I don't think I've met anyone in person (in five professional years, granted) who uses a GUI for anything Git-related except complex merges or history visualization, both on rare occasion.

Not sure why your perfectly reasonable question is getting downvoted...

<comment><USER6> i mostly use the cli, but i use a gui (git-cola) for interactively committing only part of the current diff. it's _way_ better than git add --interactive. also gitk is nicer than tig, though tig is easier to use when sshed into another server.

<comment><USER7> Incremental (interactive) commits are probably best done from within your editor. I use fugitive [1] for Vim, there's magit [2] for Emacs, and probably a plugin for your favorite IDE, or ST2.

[1] <https://github.com/tpope/vim-fugitive/tpope/vim-fugitive>

[2] <http://www.emacswiki.org/emacs/Magit>

<comment><USER6> what does fugitive do for interactive commits that beats git-cola? i love vim for single-file things, but once it comes to a global project view i usually prefer to use another tool.

<comment><USER7> I have never use git-cola, so I can't compare, but for an overview of fugitive's features, you should probably look into the Vimcasts on that subject. There's overall five videos, this one is the first:

[http://vimcasts.org/episodes/fugitive-vim---a-complement- to-...](http://vimcasts.org/episodes/fugitive-vim---a-complement-to-command- line-git/)

</comment></comment></comment></comment></comment></comment><comment><USER8> A warning about the ours and theirs commands: when you're rebasing, they will do the exact opposite what most people await them to do (thanks to git rebase's implementation).

From the git rebase man-page, --merge: Note that a rebase merge works by replaying each commit from the working branch on top of the <upstream> branch. Because of this, when a merge conflict happens, the side reported as ours is the so-far rebased series, starting with <upstream>, and theirs is the working branch. In other words, the sides are swapped.

[https://www.kernel.org/pub/software/scm/git/docs/git- rebase....](https://www.kernel.org/pub/software/scm/git/docs/git-rebase.html)

</comment><comment> c-oreills Also, any code that isn't pushed to a remote doesn't exist. Or, it won't when your hard drive unexpectedly fails and your feature branch disappears. =)

<comment><USER9> You should be using file backup on any system with code on it. It is so cheap to do this today, it is a no brainer. Apple Time Capsule, Crashplan Pro, etc.

<comment><USER10> The only non-replacable thing on my development machine is the code. It makes more sense to me to always push my feature branches up to the server, which is backed up, than for each dev machine to be backed up separately.

<comment><USER11> If you rebase a lot, then you want to avoid pushing code constantly until you get it where you want it.

<comment><USER12> One of the many reasons not to rebase code that's been pushed already.

<comment><USER11> As far as I know there's only one reason not to rebase code that's been pushed.

My point was that pushing constantly as a backup mechanism isn't an option if you intend to rebase frequently (unless you're the only developer on the project).

</comment></comment></comment></comment></comment></comment><comment><USER13> This command has a mistake in it:

      ours   = "!f() { git commit --ours $@ && git add $@; }; f"

it should be

      ours   = "!f() { git checkout --ours $@ && git add $@; }; f"

<comment><AUTHOR> Thanks, I've used an alias for checkout, "co", which I wrongly expanded when I wrote up the article. I've corrected it. Proofreading is another way not to get fired.

<comment><USER14> Has anyone ever gotten fired for making a git or other version control "mistake?"

<https://news.ycombinator.com/item?id=5513353>

<comment><USER15> Most certainly. I've witnessed it. It was a really bad mistake though.

</comment></comment></comment></comment><comment><USER16> "...sometimes php developers commit configuration files..."

needless jab, imo.

<comment><USER17> yes. This is the first thing I fix on most Rails projects I inherit. Hardly exclusive to PHP.

<comment><USER18> Oh dear, you aren't supposed to commit configuration files? Is this a security thing? What's the proper way to distribute config files to to the server and other developers?

"sometimes php developers commit configuration files and things that are used in production where they shouldn't be."

Not sure if I'm parsing this correctly. Should the files not be in production or should they not be committed? Is this just about overwriting the development configuration in the config file?

<comment><AUTHOR> An example scenario might play out thusly: Fred checks in the production configuration credentials (lets say mysql configuration for this example) in a file called passwords.php. Senior developer Bob Van Gogh checks out the project but needs to connect to his local mysql instance to develop. He edits the configuration file and hacks away on his feature. Somewhere along the way he accidentally commits passwords.php with his changes. Eventually his code is deployed and suddenly the app servers can't connect to the database. Bob's no good at football but he's a good developer and now thanks to that accident his reputation is tarnished beyond the football pitch too.

Configuration like that should be managed by something that isn't susceptible to these accidental changes.

As you mention it, security is an issue too. The fewer people who know the passwords to anything the better and the more you can keep the passwords from going over the wire the better.

<comment><USER18> Cool, thanks for the explanation. I usually have the development config in the repo and the deployment script overwrites it on the server.

<comment><USER19> That's better than the converse (default is prod, yikes!) but there's a risk of a prod server using the dev config, which might appear to work unless your dev environment is firewalled off. I prefer having an invalid or unusable config checked in, so the system doesn't even come up until I deploy the config I intend to use over it.

</comment></comment></comment></comment></comment></comment><comment><USER20> With regards to merging, I prefer using a merge tool such as Meld. Whenever you're in a merge conflict, just run git mergetool.

Meld is pretty easy to learn as long as you know to use shift-click to delete a chunk and ctrl-click to copy a chunk instead of replacing.

</comment><comment> guard-of-terra Git power usage looks dangerously like accounting.

<comment><USER21> Not all that complicated and follows a simple set of rules?

</comment></comment><comment><USER22> I realize that this post is targeted more towards advanced git users but it would be immensely helpful if you could add 1-2 examples to the every section (you only have some for the first section)

</comment><comment><USER23> These are great tips. And so is the other post about Git Koans posted here today.

I'm a bit of a git fan and while such tips pique my curiosity and delight the git geek in me, is it actually wise to use these on a day to day basis at your job? Doesn't the argument about 'clever code v/s clear code' apply to highly configurable tools like git? While pairing with others or even using a common dev box, I like to use plain vanilla CLI git without intricate aliases, without intelligent git hooks, or other fancy extensions as far as possible.

<comment><USER24> What post about Git Koans? I did a google search, but nothing came up.

</comment></comment><comment><USER25> Snapshot stack? Huh.

git checkout -b

seems a lot simpler.

<comment><USER26> Simpler indeed. That's actually what stash does internally.

I usually don't make a separate branch, but just commit it in the current branch. Then you can rebase or amend later. You never need 'snapshot' if you know rebase -i.

<comment><USER27> You can also just `git reset HEAD~1` if you want to have your index reflect the changes rather than just working on top of an empty index in a new commit. My workflow is a --no-verify commit on the branch, then when I come back, just reset to the previous commit and continue.

This is pretty much identical to stashing, though I prefer it since it means the part of git I use is smaller.

</comment></comment></comment><comment><USER28> we're also using a small script[1] that prevents committing debug statements by mistake. We put it as a pre-commit hook and also as a standalone check on our CI. It saved us from embarrassing mistakes in production several times...

[1]<http://stackoverflow.com/a/14738093/305019>

</comment><comment><USER29> > Get everything you can into git hooks

This is a great idea, and it's one that my company provides: <https://circleci.com>. You can run standard tests, but also linters and whatever you want to increase your code quality. Users report higher productivity, and shipping code faster!

<comment><AUTHOR> That's a nice, solid feeling product. I'm going to check it out properly soon.

<comment><USER29> Awesome! Feel free to ask any questions.

</comment></comment></comment><comment><USER30> I don't understand the part about .gitignore not working for passwords.php: _because that's committed too, so then you risk someone forgetting about their valid edits of the file later_.

<comment><AUTHOR> Ah, I've just tried this locally. I was sure an edited, already checked in file would remain 'hidden' if in gitignore. My mistake, will update the article.

<comment><USER30> Gotcha, I love those "them and us" commands, thanks!

</comment></comment></comment><comment><USER31> What's the reasoning behind the hack "!f(){}; f" getting shell arguments to work properly?

</comment><comment><USER32> Does anyone here know of a good 3-way merge tool for Git that's available on OSX?

<comment><USER8> KDiff3 has worked nice for me and it seems to be availabe for OS X too: <http://kdiff3.sourceforge.net/>

(however I have not tested it on an OS X)

</comment></comment><comment><USER33> What is the difference between minimal and patience for git diff?

</comment><comment><USER34> Seriously, command line for this sort of stuff? Also being stressed over source control when it is not deleting something permanently? Really?</comment>


A failed takeover of T-Mobile would cost AT&T as much as $6 billion - <AUTHOR> http://www.reuters.com/article/2011/05/12/us-mobileusa-att-breakupfee-idUSTRE74B5H220110512

<comment><USER2> In that case, who's up for some picketing?</comment>


What's New In Python 3.3 - <AUTHOR> http://docs.python.org/dev/whatsnew/3.3.html <comment><USER2> I find a lot of 3.x new features to be improvements from 2.x but everyone still uses 2.x. I fear that we will be on Python 4.x by the time 3.x adoption starts to actually happen en masse.

From what me and my coworkers have discussed we are basically all waiting on Django to get Python 3.x adoption. I've tried submitting multiple patches for this and helping Django as much as possible but they don't seem to want outside help.

Come on Django, come on, a lot of us are waiting for you.

<comment><USER3> then there's appengine, just now got up to 2.7. it will probably be another few years before it's on 3.x. doesn't fedora still ship with 2.4? ideally we would all like new toys, but reality sucks most of the time.

<comment><USER4> _doesn't fedora still ship with 2.4_

You're confusing Fedora and Red Hat. Fedora is generally very cutting edge and has been shipping with 2.7 for quite a while now, Red Hat is far more conservative and was, at least up until the latest release, shipping with 2.4

<comment><USER5> for RHEL 5, it's Python 2.4, for RHEL 6 it's Python 2.6.

</comment></comment></comment></comment><comment><USER6> I am not really that excited about any of these features that's in 3.3 (or even in Python 3).

The biggest problem I have is that Python 2 works "good enough" and upgrading to Python 3 does not have many benefits, other than lots of work and slower performance. I guess a lot of people feel the same way, hence the slow or non existing adoption of Python 3. I guess Python 3 might end up as Perl 6 if this continues since we keep investing time on Python 2.x libraries and features.

What we need is a reason to upgrade and the killer feature of Python 3 could be performance. I would upgrade to Python 3 in a instance if it offered a lot better performance than Python 2.

How do we achieve better performance? Adopt PyPy as the reference implementation for Python 3 and all future references. Making PyPy a centerpiece of Python 3+ would probably mean it would mature faster.

PyPy is focused right now on Python 2.X, but I would rather see it focus on the future of Python and being a killer feature of Python 3+.

<comment><USER7> I find your claims are unsubstantiated and would require some evidence to be convincing.

For example, the performance of Python 3.0 was slow on I/O operations. The reason was because the I/O modules were written in pure-python in order to get the ball rolling. This wasn't a bug. However, the code was eventually ported to C in 3.1 and unsurprisingly the performance improved: [http://www.gtsystem.eu/blog/2009/08/improved-performance- of-...](http://www.gtsystem.eu/blog/2009/08/improved-performance-of- python-31/)

And that's an old post from 2009! The performance is much better today.

Features they're releasing in this new version include zero-copy in os.copyfile() which is totally sweet. No user-space buffers involved in transferring bytes from a file to a socket. This should speed up such operations well past what any version of python 2.x is capable of.

There isn't a feature in Python 3 that is not substantially better than 2.x -- they're fixing all the fiddly bits and producing a much better language. There is no feature they can create which will open the dam to a flood of porting projects. The reason is that the problem is a social one.

An honest-to-goodness effort to port the large libraries requires a plan to support the existing 2.x versions alongside the 3.x versions so that the people who are still running applications built on the old versions will still work. This requires extra effort that is difficult to acquire in open source projects let alone commercial ones.

Even if the Python 3 devs added a feature that materialized ponies out of thin air there would still be projects running the 2.x code.

<comment><USER8> Yep. I won't port a single bit of my existing code until 100% of the libraries I depend on are ported first. As much as I like Python 3, it just doesn't make any sense for me to deal with it right now.

<comment><USER7> Part of what I was trying to get across is that there will never be a compelling reason to make the port. It will never "make sense" so long as what you have now continues to work.

If you're ever going to make the port, _you_ have to decide to do it and make the effort. Nothing the Python 3 devs release will ever convince you to port otherwise.

</comment></comment></comment></comment><comment><USER7> I'm pretty excited for the small changes like zero-copy and the 'x' file open flag. Oh, and the new OSError exception hierarchy.

Some of these things could be back-ported to Python 2.7 as libraries but I'd much rather see a bigger push to move onto Python 3 instead.

I look forward to even more Python 3 awesomeness in the future. Each release is a compelling reason to start porting.

<comment><USER9> I wish they could add os.splice() and os.tee() on Linux, too.

</comment></comment><comment><USER10> Should we develop on Python 3.x series or 2.x series?

Libraries aren't really ready for 3.x series and developing on 2.x series is not making any sense as if 2.x ultimately goes away then migration effort on that is not worth.

At the same time 3.x ecosystem is not ready either.

<comment><USER11> The general advice I give is: "Python 3 if you can, Python 2 if you must."

That is, if you _can_ use Python 3, you should: it's the future of the language, and it feels it. I find Python 3 significantly more pleasant than Python 2; nearly all the bits that annoy me about Python are fixed in 3. Python 3 is cleaner, the standard library is de-crufted and easier to navigate, and (most important to me) handling unicode doesn't suck.

However, as others in this thread note, significant parts of the Python ecosystem haven't finished porting yet (Django, Twisted, yada yada yada). If you rely on one of those things, then stick with Python 2. If that code lives fo a long time you will have to face a porting effort later on, but that's improving somewhat as the community discovers new techniques and creates new tools.

</comment></comment><comment><USER12> The os module now has a new function: pipe2. Is there a reason why they didn't give it a better name, like pipe_with_flags?

<comment><USER13> The underlying syscall and libc function are called pipe2.

</comment></comment><comment><USER14> I think they really need a killer feature in the 3.x branch to drive adoption. Any ideas?

<comment><USER15> I don't think they do, myself. Adoption will and is happening gradually. More and more libs are being ported, and new Python coders often learn "Python 3 and how 2 differs" (rather than the other way around), e.g. thanks to Lutz' book. Eventually there just won't be any reasons left to use 2, and the usual reasons to use the latest version kick in - incremental improvements and continued maintenance.

The migration was always expected to be a long-term thing, and so far has been pretty pain-free imho. But then I haven't written any code that doesn't run in 3.x since 2010, finding that 3 increasingly meets my deps and is more enjoyable and productive to code in, and when I do need to support 2 that the common subset of 2.7 and 3 is large enough to do many things.

<comment><USER14> What makes 3 more enjoyable/productive?

<comment><USER15> Unicode strings by default is a big one for me, but the little things sum up too: The removal of x*() functions in favor of making things that should return iterators just do so, removing old-style classes, various little consistency gains in standard object interfaces/protocols, lots of standard lib organization cleanups. I simply find things in Python 3 are the way I expect or want them to be more often than in 2, reducing the number of gotchas I need to keep track of. Heck, even print() is a solid improvement in my book (keyword args, hooray!) and I appreciate not needing the __future__ import for it.

The list gets longer of course if you fairly add all the things eventually backported to 2.7, e.g. set literals and comprehensions.

So, does 2.x work? Sure. Is 3 better? Yup. If I get to pick one, I pick 3.

</comment></comment></comment></comment><comment><USER16> Unfortunately, Python 3 is the new Perl 6. It offers reduced performance[1], changes some of the hardest-to-debug parts of the language (like Unicode), and capriciously introduces backwards incompatibilities. For no obvious gain!

As just one example, could Guido not have made the print statement a function through the simple mechanism of:

      from __future__ import printfn

Then new code could use printfn and old code could use print, and all would be well. But instead, literally billions of dollars will be wasted changing every single print keyword statement to a print function invocation. Sure, you can use 2to3. But the tool is that worst of all worlds, a compiler that doesn't really work 100% and actually reduces the performance of your code in the compilation process.

For those who do not want to waste their time on this port, Python 3 is going to accelerate the move towards full stack JS just like Perl 6 accelerated the move towards Python/Ruby. This JS stack will be MongoDB + node + Backbone/coffeescript or some similar permutation.

After all, if you are going to literally have to recompile your language with 2to3 and deal with all the edge cases, why not go whole hog with something like emscripten[2] or a souped-up pyjamas[3] to convert your legacy Python 2 code to JS? Then people just need to start porting C/C++ numerical libraries over to V8 through something like v8-juice[4] and we will have all the missing pieces.

[1] [http://docs.python.org/release/3.0.1/whatsnew/3.0.html#perfo...](http://docs.python.org/release/3.0.1/whatsnew/3.0.html#performance)

[2] <https://github.com/kripken/emscripten/wiki>

[3] <http://pyjs.org/>

[4] <http://code.google.com/p/v8-juice/>

<comment><USER17> > > [http://docs.python.org/release/3.0.1/whatsnew/3.0.html#perfo...](http://docs.python.org/release/3.0.1/whatsnew/3.0.html#performance)

The thread is about 3.3, so you link to a 3.0.1 release note? That is three years old.

> literally billions of dollars will be wasted changing every single print > keyword statement to a print function

I'd love to see the math on this, especially because I did it in a matter of minutes across all of my code.

<comment><USER16> > 3 years old

I'm pretty sure they'd have announced it if Python 3 ever got faster than Python 2. But this is not mentioned in the 3.1, 3.2, or 3.3 notes on performance:

      http://docs.python.org/dev/whatsnew/3.1.html#optimizations
      http://docs.python.org/dev/whatsnew/3.2.html#optimizations
      http://docs.python.org/dev/whatsnew/3.3.html#optimizations

> see the math

That one is easy. The Python 3 conversion is a serious project for core devs at Django and Numpy. Check out their mailing lists about what this takes/took.

[http://blog.jarrodmillman.com/2009/01/when-will-numpy-and- sc...](http://blog.jarrodmillman.com/2009/01/when-will-numpy-and-scipy- migrate-to.html)

      While the above procedure of using the 2to3 tool works
      relatively for pure Python code, there is no automatic
      conversion tool for extension code. NumPy is mostly
      written in C and makes extensive use of the Python C-API.
      So converting NumPy will require much more than running
      the 2to3 tool.

[https://docs.djangoproject.com/en/dev/faq/install/#can-i- use...](https://docs.djangoproject.com/en/dev/faq/install/#can-i-use-django- with-python-3)

      ... it will be a while before most Python software catches
      up and is able to run on Python 3.0. For larger Python-
      based software like Django, the transition is expected to
      take at least a year or two (since it involves dropping
      support for older Python releases and so must be done
      gradually).

A "year or two" of the core Django team's time is easily several million bucks. Multiply by the Python codebases of every company on this list [1], and everyone on github, and every egg out there, and we are talking billions for the conversion.

[1] <http://wiki.python.org/moin/OrganizationsUsingPython>

<comment><USER18> > I'm pretty sure they'd have announced it if Python 3 ever got faster than > Python 2.

According to this blog post, 3.2 performance now exceeds 2.6 and 2.7, using the same pystone benchmark that the 3.0 release notes refer to:

[http://www.levigross.com/post/2340736877/pystone- benchmark-o...](http://www.levigross.com/post/2340736877/pystone-benchmark- on-2-6-2-7-3-2)

<comment><USER19> From the full article, "Python 3.2 [beta] looks promising coming out just a little faster than Python 2.7.". This same article has PyPy coming in at 3 times as fast as Python 3.2 and Python 2.7 on the pystone benchmark, but if you have used PyPy it is not fast.

Looks like we need another benchmark. Does anyone have the Python 2 code from the Shootout? It seems to have been removed so that you can no longer compare Python 3 to Python 2 directly.

[http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...](http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=python3&lang2=yarv)</comment></comment></comment></comment></comment>


Python Serialization Performance - <AUTHOR> http://www.kurtsp.com/python-serialization-performance.html <comment><USER2> > Disable Schematics Validation ... There's a cool Python trick to create an > object while skipping the __init__ function.

Yes, but now every single time you update the library which provided the base class, you need to re-verify that __init__ doesn't do anything new. May be worth the tradeoff, but it really should be noted.

</comment><comment><USER3> Seems like a good use case for protocol buffers [1].

[1][https://developers.google.com/protocol- buffers/?hl=en](https://developers.google.com/protocol-buffers/?hl=en)

<comment><USER4> It might be that they consider it important to be able to interrogate the in- memory or on-disk representations without the help of a decoding step. Protobufs are great for getting objects into a nice compact format to throw on the wire, but god help you if you end up with multiple actors filling up a queue with inconsistently encoded objects.

<comment><USER5> doesn't Apache Avro solve this problem?

</comment></comment></comment><comment><USER6> TL;DR: Things get faster if you disable validation and parse dates using more specialized code. Duh.

It's humorous when someone who presumably cares about performance tells you they use Python. Python is a wonderful language, but performance is not what it is designed for. Basically _anything_ that does not require an interpreter to run will be 10-30x faster on the same hardware, and most will also consume less RAM and be able to use more than one core on the system efficiently. It used to be that Python's lack of performance didn't matter because disks and networks were so slow things were IO bound. In more and more cases that's just not true anymore. You could be easily reading at 1GB+/sec and pushing 10-20Gbps to NICs, depending on the hardware.

<comment><USER2> It depends what "using python" means though. Cython is pretty good at optimizing basic code. Numpy will process your matrices and vectors using specialised libraries faster than most manual C approaches. Shedskin will give you a nice code framework which you can optimise in parts that matter. (insert other specialised examples)

CPython is slow as an interpreter, true. "Programming in Python" may or may not be many times slower than compiling the comparable code in other language. Depends what you're doing and how you're doing it.

Also, I care about performance in any language to some extent. If I can write a backup bash script that takes 2h, or write one that takes 20min, I do care about performance and will choose the second one. Why shouldn't I?

<comment><USER6> Even Cython will be several times slower than a carefully tuned C/C++, Java, C# or Go program for most practical problems. And at least in the case of C/C++ it'll also likely use several times more RAM. Now for a company like Uber it may not matter if something is 3x slower and uses 3x the RAM, just throw more hardware at the problem, but if you're going to introduce typing into Python, you might as well go with a language where typing is not optional, and which, more importantly, has been used in production by thousands of teams over the past decade or more. Of the languages I listed, only C++ is not really viable for most programmers.

As to caring about perf, you shouldn't care about it until you have to. Take that 2h vs 20min example, for instance. If you only need to run it a few times and there's plenty of time available, who cares how long it takes. If the 2h one is easier to write that's by all means what you should do. OTOH if you're under severe time constraints and need to run it every hour, then obviously 2h script won't do the job. Or alternatively if 20 min script takes the same time to write as 2h one, then of course you should go with it. All too often I see people optimizing things that don't matter one iota, simply because they like things to be fast. Something gets executed once a day and runs for 5 minutes? Let's spend two weeks making it complete in 30 seconds. As long as the employer is paying, why not.

<comment><USER7> Cython is the same speed as a carefully tuned C/C++ program; carefully tuned, Cython maps directly to C/C++. I've done many benchmarks of low level numerical code when implementing SageMath (which uses Cython for several 100K lines of code).

<comment><USER6> As someone who has spent almost 20 years (on and off) writing C and C++, I don't believe it. C/C++ lets you go as close to hardware as you would possibly want. Want SIMD? Easy. Want custom memory allocation (a big deal if you allocate/deallocate a ton)? Sure, why not. Want to profile and optimize cache locality and memory layout? Knock yourself out. Memory alignment? Yup. Branch hints? Of course. I could continue with this, but as someone who has written performance-sensitive code you already know most if not all of this. It's not a coincidence that e.g. high performance linear algebra libs are written in C.

And it baffles me that anyone would even consider writing 100KLOC+ project in something as lax as Python. That's just asking for trouble.

<comment><USER8> >It used to be that Python's lack of performance didn't matter because disks and networks were so slow things were IO bound. In more and more cases that's just not true anymore.

That's generally a valid statement. But it's why PyPy and Nuitka exist. Pyston and Pyjion are up and coming in this area.

>And it baffles me that anyone would even consider writing 100KLOC+ project in something as lax as Python. That's just asking for trouble.

That's why Python 3.5 has type annotations. It increases the amount of sane usecases for Python going forward.

Let me add I'm with you though in your general thought. The DB/IO bottleneck myth needs to die. We do need more performance, on the order of Elixir. CPU performance at that level or above removes a whole class of application issues. Not sure C's performance is needed though unless you're doing systems programming.

I just happen to like Python as a language, so happy to fly the flag on the various solutions to make it fit that truly needed aspect.</comment></comment></comment></comment></comment></comment>


How to Charm a VC Into Mentoring You - <AUTHOR> http://gigaom.com/2010/12/28/how-to-charm-a-vc-into-mentoring-you

<comment><USER2> "After about 20 emails, he'll know that you are serious, and he will answer. But know that those 19 emails leading up to the one that does get answered were not in vain."

I felt slightly sick reading this article. Maybe that answer is to tell you that the last 15 emails kind of creeped him out.

</comment><comment><USER3> Or maybe not do any of this and just focus on building a high growth business so that one day VC's share notes on how to charm an entrepreneur for taking your money.

<comment><USER4> I second that. I find it "interesting" how this whole VC game is written from the VC point of view..."you need us, we don't need you"..oh really? I see it the other way. I don't really need your money, why again should I be cutting you in?</comment></comment>


Show HN: Add Real-Time Collaboration to Excel 2013, 2016 and Online - <AUTHOR> http://www.quant.cloud <comment><AUTHOR> has been in development for a year and used privately in a trading environment where real-time is important. we figured let's put it in the public and see what other uses we can find. this is the first public release and we have lot more features we want to incorporate over.

</comment><comment><USER2> Curious regarding the story behind its development.</comment>


Just launched BeCouply Dates: we send couples on an epic date every month - <AUTHOR> http://www.becouplydates.com

<comment><USER2> Sounds very interesting, but what kind of system do you have in place for configuration of the date activities?

For example, if a couple prefers to have dates with just themselves, vs couples who want exclusively group style dates? Or a couple that has some kind of physical disability and thus wouldn't be able to complete a "surprise" date that included, say, skydiving?

Cool idea, however. Best of luck with it!

<comment><AUTHOR> Thanks for the feedback! Initially, any configuration that needs to happen will be via concierge, as we want to have the best customer service (and highest resolution feedback) as possible.

</comment></comment><comment><AUTHOR> First city we've launched in is San Francisco. I've set aside a promo code for fellow HN'ers: HACKERNEWS</comment>


Examples of beautiful Go? - <AUTHOR> http://programmers.stackexchange.com/q/82179/19141

<comment><USER2> To a certain extent the question is not correct. Go was not designed to be beautiful, it was design to be readable. So the code can look quite pedestrian (e.g. for { } loops where other languages might have other constructs).

I believe this to be a win because learning and writing the language are fast. There are some nice 'a ha' moments (such as when you understand interfaces), but mostly the code is (in a good way) boring.

It's also a small language. I think it was designed for people who want to get things done, not for people who want to find the cleverest (i.e. least-number- of-characters) way of doing it.

The way concurrency is built into the language (based on sequential programming with channel based communication) further reduces the potential complexity. You just write sequential code and let the Go runtime handle the rest.

<comment><USER3> Beauty is inherently linked to readability, at least in my opinion.

If you look at typesetting, a lot of care is taken to tweak letter spacings and getting the font just right. This makes the work easier to read than a giant wall of text, and visual beauty comes as a natural side effect of that optimization.

Code really isn't any different. While there is certainly some variance by the beholder, code that is generally easy to read is going to naturally look beautiful. Additionally, and perhaps more importantly, if the code is beautiful, it will attract you to maintain it.

I am still a Go newbie, but my initial impression is that certain constructs make it more difficult to write beautifully than it should, which only serves to detract from the readability (not talking clever one-liners here – which shouldn't even come up in beauty discussions). However, given that I am new to the language, I may just not be yet able to express things as well as I could.

<comment><USER4> Coding is completely different from typesetting, otherwise we wouldn't all be using monospace fonts.

Beauty's more subjective than readability, but most of the time a beautiful, elegant, recursive structure takes more time to figure out than your ho-hum for loop, in my experience at least.

<comment><USER5> Not everyone. I certainly don't :-). A significant minority of Go users come from or like Plan 9, and they use acme or sam, Rob Pike's editors, which by default display text in a variable width typeface.

<comment><USER4> Huh, so I guess you guys just use tabs rather than spaces to get things to align properly?

<comment><USER6> we use whatever `go fmt` outputs (which, yes, happens to be tabs).

</comment></comment></comment></comment></comment></comment><comment><USER7> "Because of that, I'm having trouble persuading myself that Go is much more expressive than competitors" Beauty is in the eye of the beholder. While one programmer might say beautiful code is expressiveness (ex. performing a one liner quick sort), that is not what most Go developers I know see as beauty. Beautiful Go in my opinion is code that (in increasing importance):

      1. runs fast
      2. uses little memory
      3. is easily made (or is) concurrent / parallel
      4. is transparent (the intuitive run time complexity of operations is apparent, no hidden O(n..) operations, etc)
      5. is easy to maintain

If this code happens to be more verbose than say Java, so be it, it is still beautiful. On an anecdotal note, most large C++, Java and node.js projects I have ported to Go have ended up being fewer LOC in Go.

<comment><USER8> How does a Go solution compare to a Perl, Python, or Ruby solution? The latter languages offer quick solutions to problems but they don't often scale to large projects built by large teams.

<comment><USER9> Binary builds are one advantage. Compile your go application and deploy it. No need to also install Ruby, gems etc.

You can cross compile as well. IE compile for Linux from OS X.

[http://dave.cheney.net/2012/09/08/an-introduction-to- cross-c...](http://dave.cheney.net/2012/09/08/an-introduction-to-cross- compilation-with-go)

<comment><USER10> Imagine that Go were used to write most components on a system. One security vulnerability in one package and you don't replace just one library, you'll have to reroll every binary (or package if you are maintaining a Linux distribution).

Also, since there is no version management in Go packaging, you better hope that every program uses the API of the latest or fixed version.

<comment><USER11> > Imagine that Go were used to write most components on a system. One security > vulnerability in one package and you don't replace just one library, you'll > have to reroll every binary (or package if you are maintaining a Linux > distribution).

Imagine that a shared library were upgraded, and it contained a new vulnerability. This vulnerability now automatically exposes any program that uses said said library.

Trade offs :-)

(Compiling Go is fast. Re-rolling a binary isn't a Big Deal.)

> Also, since there is no version management in Go packaging, you better hope > that every program uses the API of the latest or fixed version.

Simplicity has a price. But there's no reason why an external tool cannot be made to handle versioning.

<comment><USER10> _Imagine that a shared library were upgraded, and it contained a new vulnerability. This vulnerability now automatically exposes any program that uses said said library._

Production systems normally only replace shared libraries to fix vulnerabilities. So, that's a non-argument.

On non-production systems, it's far easier to replace one vulnerable library, than tens of vulnerable Go programs. That is, if you know which Go program was using what version of that package again.

<comment><USER12> Do you feel comfortable ripping out a shared library used by many different binaries on a production system and replacing it with a new one? I would be pretty scared to do that.

I would rather replace all the binaries separately. If one of the new binaries didn't work, I could go back to the old version.

I do agree that the shared library approach uses less network bandwidth, but is that really a big problem these days? Unless you're sysadminning over dialup, chances are you don't really care. The size of binaries has plateaued at a meg or two even as networks have continued to improve.

<comment><USER10> Sure, I know when the ABI changes and when not. For security fixes it's pretty safe to do. In fact, Debian Stable et al. do it all the time.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> Caveat: lots of subjectivity here.

My impression is that Go and Lisp are similar here. Neither is particularly pleasant to read in the small. Lisp because of all of the parens and the sometimes "backwards" dataflow of nested functions. Go because of the "imperativeness", the frequent manual returns for errors, the mandatory {} for blocks.

In both cases, that was a deliberate choice in order to get _simple_ syntax. The beauty they are focused on is larger-scale beautiful _semantics_. Lisp with macros, first-class functions, etc. Go with interfaces, goroutines, and channels.

Where some languages treat the syntax as a first-class feature, I think Go and Lisp treat it more as a means to an end. That being said, in both cases, practitioners of those languages do specifically like their syntaxes. It's just not a major focus of the language designers' time.

<comment><USER14> _> Lisp because of all of the parens and the sometimes "backwards" dataflow of nested functions._

I've come to believe that the second part of this statement really is the primary reason why Lisp drives some people absolutely nuts. The parens are really just a distraction and "easy" justification for not liking the language.

It makes sense, though. When you have to read both "outside in" and "bottom up", a lot of your acquired reading abilities (left to right, top to bottom) are in tension with the code you're trying to understand.

At least in Clojure, the ->> family of operators ("threading" macros) are doing a good job helping to alleviate this. Maybe they're available in other Lisps, I don't know.

 _EDIT:_ found a reference to these macros in Emacs Lisp: <http://emacswiki.org/emacs/ThreadMacroFromClojure>

<comment><USER13> > I've come to believe that the second part of this statement really is the > primary reason why Lisp drives some people absolutely nuts.

Agreed. This is a major reason why Lisps read wrong to me and is one of my favorite things about conventional subject.verb(object) syntax in OOP languages.

My own language[1] has Lisp-like semantics where methods are lexically-scoped and not attached to classes but retains something close to OOP syntax because I think that's such a readability win. For me, this is the best of both worlds.

[1] <http://magpie-lang.org/multimethods.html>

</comment></comment></comment><comment><USER15> Go fmt is my single favorite feature about the language.

Coming from a background in Lisp, I don't find much in Go that seems very 'elegant' or 'beautiful'. What I find is that everything - including the Go source code itself - is perfectly standardized (and therefore immediately readable).

I don't have to worry about different coding styles, about semicolons vs. no semicolons[0], about having more than one way to express the same code. I can skim the code easily because the structure is so uniform across all standard and community libraries.

That's a different kind of beauty from chaining macros and cons cells, but it's beautiful nonetheless.

[0]<https://github.com/twitter/bootstrap/issues/3057>

<comment><USER9> Not only does gofmt make the code consistent for people, it makes it machine consistent. Once the code is "fmted" parsing, replacing, etc is simple.

Which, btw, gofmt does does pattern replacement.

<http://golang.org/cmd/gofmt/>

<comment><USER16> The pattern replacing is awesome. It can do a lot of refactoring.

[http://talks.godoc.org/github.com/sunfmin/talks/2013/gofmt.s...](http://talks.godoc.org/github.com/sunfmin/talks/2013/gofmt.slide#1)

<comment><USER17> If this is refactoring, then you never used a proper IDE with refactoring support.

Slide 5 is the proof this is no better than search and replace.

<comment><USER18> Honestly, that's not a very good representation of what gofmt can do.

This is a much better example: <http://research.swtch.com/gofmt>

gofmt -w -r 'x[i:len(x)] -> x[i:]' *.go

Note that this is not a regular expression... it's looking for go expressions that match that pattern.

So, for example, this will catch this:

a := charts[start:len(charts)]

and convert it to this:

a := charts[start:]

<comment><USER10> True, it's much more than simple search and replace, since it produces an AST, which provides more powerful refactoring.

It's also not very spectacular, since it's what Java IDEs have done for ages, plus incremental compiling :). (Or code analysis tools such as Sonatype.) Go is just playing catch-up here.

The one thing they did very well is dictating the code style with gofmt. You may not like it, but at least there is once standard. Though, one wonders how many developers and businesses use whatever layout Eclipse or Netbeans use out of the box ;).

</comment></comment></comment></comment></comment></comment><comment><USER19> Conciseness was not a goal. Simplicity and regularity were. IN this case, beauty is in the eye of the beholder.

<comment><USER20> Agreed.

</comment></comment><comment><USER21> Omg ruby is so much better. K thnx bye.

<comment><USER20> LOL. I know this is a joke, but I'm actually a ruby dev myself diving into Go. I find it to complement Ruby extremely well. Both have their strengths and weaknesses.

</comment></comment><comment><USER21> Sorry didnt think this post had enough troll in it to qualify as an authentic go discussion.</comment>


We launched our app for SXSW – introducing Meeps - <AUTHOR> http://itunes.apple.com/us/app/meeps/id499966807?ls=1&mt=8

<comment><USER2> As one of the folks working on this (I did some of the iOS programming), I just want to say that I had a blast working with Mat and Sean.</comment>


Stripe has raised $150M more at a $9B valuation - <AUTHOR> http://www.recode.net/2016/11/25/13746264/stripe-9-billion-valuation-150-million-funding-series-d <comment><USER2> Stripe, please, please, invest in a better PayPal alternative. That is:

* let people hold money into their Stripe account instead of transferring to a bank immediately

* let people transfer money from their Stripe balance to any other account's Stripe balance for free (PayPal charges a fee for "cross-border" transactions)

* make it possible for marketplaces to pay their workers through Stripe (PayPal and sometimes Payoneer are the only choices now). Workers can then withdraw to their bank accounts from Stripe balance, or use it to pay directly for other stuff on the web

* have a low commission for merchants, if not free, for payments of goods using Stripe balance

<comment><USER3> If they hold money in their Stripe account, it would transform Stripe into a money transmitter. The regulations involved are completely different and immense and would change Stripe into a different company. Also, the regulations are different for every state they're in, with different requirements on the board of directors (like NY state). A lot of the things they do as a processor right now would be impossible if they turned into a money transmitter. They would turn into Paypal not because they want to, but because the regulators would force them. Including everything that's bad about Paypal.

<comment><USER4> > Including everything that's bad about Paypal

Not everything that's bad. A sucky API and UI isn't because of regulations.

</comment></comment></comment><comment><USER5> I'd like to see Stripe go public instead of raising additional VC capital. They could really spark a series of tech IPOs strengthening tech stocks. I don't have any insider knowledge (besides my research when working on my failed startup Charge Control[1]), but I would be shocked if Stripe is not profitable.

[1] [https://justink.svbtle.com/stripe-put-my-startup-out-of- busi...](https://justink.svbtle.com/stripe-put-my-startup-out-of-business- before-i-launched)

<comment> eric-hu I don't have any insider knowledge either, but I have this impression that you lose operational efficiency when you go public. For all the heat that VCs get for pressuring their portfolio companies to grow 10x, it seems like answering to the public market is even more wasteful.

This is just an impression though, I don't have anything to back it up.

<comment><USER6> So what's the end game though? Investors want their return at some point.

<comment> eric-hu The end game is that you have a product market fit figured out and then you go public. Pretty much the opposite of what Twitter did.

</comment></comment></comment></comment><comment><USER7> Fun to see the rivalry between Stripe and Square play out. This line though has me a little puzzled, however:

>"On the flip side, Square is more diversified, generating revenue from non- payment products such as its Square Capital lending business and Caviar restaurant-delivery operation."

Isn't Caviar widely known for being a massive money-loser for Square?

[http://www.bizjournals.com/sanfrancisco/blog/techflash/2016/...](http://www.bizjournals.com/sanfrancisco/blog/techflash/2016/10/square- caviar-uber-grubhub-yelp.html)

<comment><USER8> > _Fun to see the rivalry between Stripe and Square play out._

One has a part-time CEO tanking Twitter and the other doesn't. This is not a rivalry.

</comment></comment><comment><USER9> OT but Stripe has some of the most beautiful front-end design I've seen on a major financial product. All their pages are just so beautiful, yet functional

</comment><comment><USER10> I would like to start a developer-first payment processor in my country, where we do not have access to PayPal or Stripe.

What would you guys say is the biggest hurdle to overcome to get off the ground? Finding a bank to back your transactions? Securing customer card details and connections? Dealing with fraud? Insurance in case of data breach? Or none of the above?

Also, what kind of upfront costs would I need to factor in? I've been looking at local compliance requirements and regulations, and they seem doable (on the order of $1k USD). I plan on working on this alone, at least initially.

<comment><USER11> First off, congrats on taking the initiative. It's one thing to complain about how much a situation sucks, and another entirely to take it upon yourself to actually do something about it.

You're partially right. The biggest issue medium to long-term would be getting a bank to back you. That doesn't have to be a show stopper from day 1 though (assuming you're willing to assume some personal liability, as you will be in violation of the ToS of any service provider you use).

It all comes down to your risk appetite. Essentially, you could run your own API that would wrap Stripe/Braintree's API and kickstart your business that way. This would require a US entity, but with Stripe's Atlas this is a non- issue.

This is fine if you're processing $10k or even $100k/mo. It gets icky when you try to get past that. As volume grows, there's increasing pressure to make sure that your setup is air-tight, something you can only get by setting up locally (Visa/Mastercard regulations prohibit cross-border processing so it's the only 100% legit way forward).

Herein lies the challenge. Banks in the Middle East (which I presume is where you are targeting) vary greatly in terms of what volume actually deserves their attention. For some that's $10M/mo. For others it might be less. Once you've got $100k, and have a strong upward trend, you can start having these discussions.

In short, you want to start it like you would any other business: by focus on making something people want. The bank issues can be delayed until after you've got a decent customer base. Historically, there's a 95% chance that your company would not survive (startup stats still apply). If you get past that, hit me up and I can provide more specific advice.

<comment><USER12> _Essentially, you could run your own API that would wrap Stripe /Braintree's API and kickstart your business that way. This would require a US entity, but with Stripe's Atlas this is a non-issue._

Disclaimer: I work at Stripe, on Atlas, and I'm writing here because this is professionally interesting to me.

We probably wouldn't be able to support that business, due to it being an "aggregator." (It aggregates the charges of other merchants and holds onto the funds for some period.)

These are strongly discouraged by banking partners, largely for risk reasons. For example, hypothetically suppose an undercapitalized aggregator was hit by $10k in credit losses by a fraudulent merchant. (Merchant signs up; runs $10k in charges; whoops they're all stolen cards; you ask their bank to pull $10k back but that account has been closed and whomever opened it is out in the wind.)

That $10k has to come from somewhere. Historically, what ends up happening distressingly frequently is this causes the aggregator to fail to deliver money to other merchants. Some of them fail. Their customers charge back their purchases. This increases financial strain on the aggregator. Eventually, the aggregator fails; _all_ of their merchants are greatly inconvenienced; some of them fail; thousands upon thousands of customers are adversely affected. One or more interested parties look for the nearest deep pockets and say "Hey, you should have seen this coming. You're the big, sophisticated company here. Make this long, long line of people whole."

This is why the industry largely doesn't offer credit card processing services to aggregators and, when it does, wants them to be huge, well-capitalized, and very sophisticated. The same issue makes it anomalously hard to get processing capabilities for businesses that you'd assume wouldn't cause problems, like e.g. travel agents. (One cruise company folds while holding onto customer funds; dominoes start falling as above; boom there's an $N million credit loss attributable to a company with revenues in the $100k per year range.)

There are some things which look similar if you squint but are distinguishable because the business doesn't end up holding funds they're not already entitled to. For example, Stripe Connect lets a platform split a transaction into the majority for the merchant and a fee for the platform, without the platform needing to physically have custody of the merchant's money at any point. That probably won't work for your use-case, though, since the merchant would have to be in a country we support.

We're working as fast as we can on bringing the rest of the world online. Stripe wants to be everywhere. Atlas is one initiative we're working on to make good on that (and has brought Stripe up to somewhere north of 110 countries with customers in them); we're constantly at work on other approaches, too.

If any HNer ever has a question about this sort of topic, feel free to email me -- my HN username @ stripe.com will work. I'm happy to explain things, find the right person to do so, or see what we can do regarding businesses that are at the margins. We spend a lot of time on me team and elsewhere in the company zealously advocating on behalf of our users to banking partners to get their businesses accepted.

<comment><USER13> I'm curious: FastSpring supports sellers from all over the world as their customers, despite having no local presence. It's not difficult. Why can't Stripe? I was waiting for _years_ to be allowed to use it, until MOSS happened in EU and I no longer care - FastSpring's higher fee is well worth the VAT offloading they do for me (and Stripe wouldn't because of the different setup).

</comment></comment></comment></comment><comment><USER14> I hope the employees got to sell in this round.

<comment><USER8> Stripe is in the same bucket as Airbnb, Uber et al. Transfers, even if "permitted", are blocked. Because what–are engineers going too sue? /s

<comment><USER14> That's sad. Back in my day, the last round was always C. After that you either went public or folded up. The track record of companies that raised a D was so bad that everyone feared a D out of stigma.

Things might have changed a little now, but probably not much. Companies with later than C rounds will prove to be poor investments.

</comment></comment></comment><comment><USER15> I have trouble understanding this valuation considering that it just doesn't seem like a terribly difficult market to jump into. They aren't first to the table. Is there something that's protecting their market position/ensuring that it will get better?

<comment><USER16> Whether the market is easy to jump into doesn't matter. Ecommerce is easy to jump into, but you don't see anyone threatening Amazon's position, right? It's all about your ability to execute competitively. Also, payments in particular is a regulation-heavy industry and PCI compliance is a headache all on its own.

</comment></comment><comment><USER17> Anyone guess what they will spend the cash on?

Couple plausible options

\- they aren't profitable but have huge transaction volume \- international growth \- new product development

Thoughts?

</comment><comment><USER18> Paddle has CC, Paypal, and available in my country. Win Win Win.

<comment><USER19> Does Paddle have a Ruby gem for Rails?

</comment></comment><comment><USER20> Perhaps now they will build an Android app?

</comment><comment><USER21> I don't mean to hate but why would anyone chose Stripe over Braintree? It seems the same to me + Paypal which is HUGE.

<comment><USER22> Throwaway for obvious reasons. We do approx $5MM of annual business through Stripe.

#1 reason is lock-in and momentum. Stripe has, bar none, the WORST support of any company in existence. And they don't care to ever change that, having made noise about it for years, but expending precisely zero effort on that front. We would love to move.

But we stay, because we utilize Stripe's card tokenization in order to "store" repeat customers' payment information without having to deal with PCI-DSS compliance processes. If we moved, all existing customers "stored" payment information would, by necessity, go away.

<comment><USER23> > If we moved, all existing customers "stored" payment information would, by > necessity, go away.

Not necessarily. You should be able transfer the stored card data to another provider. Many (although not all) payment processors seem to allow this.

      https://support.stripe.com/questions/what-if-i-decide-to-leave-stripe-can-i-export-card-data

<comment><USER24> I've moved a few businesses off of Stripe and never had any problem. They do it with PGP keys and go directly to the new provider so I never touch any info. Worked great.

<comment><USER25> You moved them from Stripe to where and why? I'm about to launch a product in a few months and trying to decide which company to go with. So far Stripe seems to be most favorable for the development team. But maybe there are some business things that make Stripe less desirable. Thanks for any insight.

</comment></comment></comment></comment></comment><comment><USER26> Just learned that Alphabet is reusing names. CapitalG was used before: [http://www.royalgazette.com/article/20140422/NEWS/140429952](http://www.royalgazette.com/article/20140422/NEWS/140429952)

</comment><comment><USER27> Seems odd so this means the money making isn't going that well.</comment>


The World is His Gameboard - <AUTHOR> http://www.inc.com/articles/201101/scvngr-the-world-is-his-gameboard.html

<comment><USER2> Honestly I've yet to find scvngr useful. Maybe I'm not their demo, but the app just doesn't get me excited. I've had it installed on my phone for well over a year and have maybe opened it twice? I think the idea is kind of cool, but I am not sure how it is relevant or why life ought to be modeled as a video game in the first place.

</comment><comment><USER3>
       > Companies and institutions are paying
       > $2,000 a year to north of a $1 million
       > a year to use the Scvngr platform

I'm impressed if those numbers are legit, but a $1M contract sounds pretty high to me for what is really an unproven platform.

Inc. mentions the Navy, could it be government pork?

Anyone have more insight?

</comment><comment><USER4> Maybe it's just me, but working 24-7 and keeping a sleeping bag at your desk sounds like a really easy way of burning out quickly.

<comment><USER5> You have no choice. Give in to Startup: a roller coaster of external self validation through articles (young! college drop out! attractive! pointless mission!), funding (let's raise $30M!), and high power friends also stuck in external self validation cycles (omg, another hit on my google alerts search for my name!).

When you find out you aren't the person reflected back at you externally, you do what you did the first time to get back into the spotlight. So what if you burn through $30M and still can't make money? Just raise _more_ money. Remember: shoot for the moon. Start an inferno with a match. Worst case, you get a free pity acquisition from one of your slightly older, slightly uglier, but much smarter friends.

(I must have woken up on the wrong side of my VC this morning.)</comment></comment>


Our First Pivot (or: Don't Give Up) - <AUTHOR> http://www.alexwestholm.com/business/our-first-pivot/

<comment><USER2> In my new project, I keep hearing about all the people who did it before and stopped. Some pretty big players that are household names. I'm keeping an eye on what they've done and why they had to stop while not getting drawn into the "well, if they did it and failed..." quicksand. There are key new developments that weren't present when the big guys killed their projects so that's what keeps me moving forward.

I've also been worrying about the whole "what if I find out someone else has figured this out" thing. I think your post is a swift kick that says to keep an eye out but to spend time building instead of worrying and to keep going if the market supports the innovation. Thanks for the post!

<comment><AUTHOR> Thanks for reading it, and best of luck on your project!</comment></comment>


Linux apps invade Windows Visual Studio - <AUTHOR> http://news.techworld.com/applications/3206103/linux-apps-invade-windows-visual-studio/ <comment><USER2> Original source on Miguel de Icaza's blog: <http://tirania.org/blog/archive/2009/Nov-10.html>

</comment><comment><USER3> This sounds like a good idea to me. If I was .NET developer who had no reason to make my application run on Linux but also no reason not to, I would definitely try out this add-in.

</comment><comment><USER4> This is a weak article about a pretty slick tool. (They aren't really Linux apps, they're Mono apps, but since Mono is cross-platform, they may be running on a Linux machine.)

</comment><comment><USER5> Can you remotely debug an application running on a Linux box, from within Visual Studio? Now that would be useful.

<comment><USER6> They seem to do that too :)

<http://go-mono.com/monovs/Debug.aspx>

<comment><USER5> Sweet

</comment></comment></comment><comment><USER7> Title is pretty misleading. It's just a VS add-in to facilitate Mono development.

</comment><comment><USER8> "Windows" and "Visual Studio" are two distinct products from Microsoft.</comment>


DOMJuice: The Web App Poltergeist - <AUTHOR> http://stephank.github.com/domjuice/

<comment><AUTHOR> The annotated source code is also worth a look: <http://stephank.github.com/domjuice/docs/domjuice.html>

</comment><comment><USER2> This looks pretty damn cool. It seem like this is the missing front-end to Backbone.js, and a potential alternative to the powerful but learning- curvaceous Angular.js.

</comment><comment><USER3> Dare I say, you've got to let it loose.</comment>


Show HN: Ribbit – Weekly written content for Reddit for your business - <AUTHOR> https://heyribbit.com/ <comment> to-too-two Augh, I hate this. Reddit used to be one of the places I'd go to avoid junk. Now it's filled with this 'drive traffic through outbound marketing' bullcrap.

Now I'm not opposed to well thought out articles and essays, but obviously that's not what this is. Just keep piling on the crap.

<comment><AUTHOR> We aim to subvert your expectations by only posting well-thought out written content for our customers :)

<comment> to-too-two That's all well and good, but at the end of the day, it will be an article that was conceived with the intention to sell something. Fortunately, most people can see through this. I know I can tell when I'm being sold something no matter how insightful it attempts to be. It's the lack of integrity that robs it of its value.

"Ads disguised as content can be used to describe all forms of content marketing, am I right? ;)"

Essentially, and it sucks.

<comment><USER2> It does not work this way since Google started to rely on behavioral metrics of content, not just keywords. Useful articles that people read and refer to frequently, go up, junk goes down. So creating articles with only aim to sell something is the sure fire way to anger people and waste your money. Content marketing nowadays is about producing quality content IN HOPE that it will help to sell your product.

</comment></comment></comment></comment><comment><USER3> That's a really good idea in order to promote on reddit without spamming it. Quick question though, what if the content you create does not get any traction?

<comment><AUTHOR> That's a great question. Obviously not all content that is ever published gets great reception. But we make sure that the content we create is very likely to want to read because we cater the content to the context of the subreddit. Classic data-driven social media marketing :)

<comment><USER4> I think you haven't answered his question.

<comment><AUTHOR> It was a similar question to asking "What if a Google Ad doesn't work?" And I'm saying that there will obviously be a time when an attempt to promote something doesn't get traction. What we can do is give our best effort to make sure that it does by making sure it's relevant to the people reading it and not just spam that disrespects people's attention

</comment></comment></comment></comment><comment><USER5> Advertisements that are disguised as articles will hurt your business in the long run when the jig is up.

<comment><AUTHOR> That would be more true if we aim to just spam communities. But we create relevant content that those in the respective subreddit will find valuable.

"Ads disguised as content" can be used to describe all forms of content marketing, am I right? ;)

</comment></comment><comment><USER6> Looks good

<comment><AUTHOR> Thanks! :)</comment></comment>


Artificial Intelligence Isn't a Threat – Yet - <AUTHOR> http://www.wsj.com/articles/artificial-intelligence-isnt-a-threatyet-1418328453

<comment><USER2> The Wall Street Journal will consider AI a threat when an AI running a hedge fund starts firing CEOs.

</comment><comment><USER3> 'AI will not be a separate intelligent entity, it will be the extension/evolution of existing intelligent entity, that is us.'

With respect to intellectual threat I don't think you can say that. Your assumption is that any behaviour resulting from the creation of a separate intelligent entity (no one has the slightest idea how to do this) will be predictable (or be constrained by us) - having evolved 'from us'. Why should that be?

</comment><comment><USER4> People don't really understand AI. I wrote a post about why AI is not a threat and the arguments are more of logical and fact driven then philosophical. [https://medium.com/@ankur_dhama/artificial-intelligence-a- th...](https://medium.com/@ankur_dhama/artificial-intelligence-a- threat-d525799f912b)

</comment><comment><USER5> There are seven questions in this article, and topics like machine learning and program verification are in quotes.

I don't think a competent engineer was consulted on this article.

Perhaps as a community we should elucidate in a more formal fashion to the press.

</comment><comment><USER6> I've been giving this a lot of thought lately because of Musk and Hawking. I think they are wrong, for a couple simple reasons.

1) A true AI wont care about us, or probably anything. It may just suicide.

2) Very simple to destroy. EMP, etc.

</comment><comment><USER7> In one respect, AI is already damaging the sense of self worth of swathes of humanity by making them economically redundant. This will be an accelerating threat for sometime.

<comment><USER8> While I can empathize with the emotions behind that argument, it's rather hard to be persuaded by it. Jobs can become redundant, but people can't insofar as they can be retrained. If we're talking about what harms people's self worth, I'd imagine that telling people they're redundant is a lot more dehumanizing than having them retrain for new positions.

In any case, human beings are remarkable adaptive. It's one of our most impressive traits; don't sell it short.

<comment><USER9> Easier said than done. What are they going to retrain to? As AI continues to advance, more and more jobs will necome redundant. CGP Grey did a great video on this[1]. Even if you can't completely replace humans, often times, obe person will be able to do the job that used to take several. Where do those others go? What will we as a society do if for example AI-based Expert Systems make 90% of accountants and office clerks redundant? We can't retrain all of them to become doctors and scientists, can we?

[1] [http://youtu.be/7Pq-S557XQU](http://youtu.be/7Pq-S557XQU)

</comment></comment></comment><comment><USER10> This is creating so much buzz..

I would like to say that just wait and watch. Time will tell whether it is or whether it is not</comment>