Show HN: my weekend project, Gumroad - <AUTHOR> http://gumroad.com/ <comment><AUTHOR> Over this past weekend I had the idea to build a sort of link shortener but with a payment system built-in. There have been many times in the past where I wanted to share a link - on Twitter or just through IM with a few friends - but did not want to go through the overhead of setting up a whole store.

So I built Gumroad. I coded/designed from 12PM -> 11PM on Saturday and 8AM -> 11PM on Sunday. There are still tons of features missing (I'm working on AJAX file uploading next!) but I think it's reached that - buzzword alert! - <USER2> stage where I want to see if anyone's actually going to use the darn thing (I'm thinking about taking a 30% cut).

Here's an example Gumroad link: <http://www.gumroad.com/l/hjbaod> \- I use Stripe for payments. Here are some screenshots I took while making it: <http://letscrate.com/gumroad/gumroad-progress> \- I didn't use Photoshop so no crazy time-lapses!

I think it has some potential. What do you guys think?

<comment><USER4> I love the idea! This makes it really easy to sell scripts (e.g. your own jQuery plugins or whatever) for $5 where it would normally be too much work to set up some payment processing.

The 30% cut is way too high though. Especially for higher priced links - <USER3> wouldn't want to sell my $99 game engine[1] through your service. I think something like "5%, but at least $0.30" would make more sense. But maybe having such "highly" priced links wasn't your intention in the first place?

[1] <http://impactjs.com/> (Can't mention it often enough :))

<comment><USER5> Paypal already takes $0.30 plus a small percentage. I think the service is a neat idea, but microtransactions are not a solved problem.

<comment><USER4> Thinking about it, Gumroad is the perfect application for Bitcoins:

<http://www.bitcoin.org/>

<comment><USER5> No, it isn't. Bitcoins are clever and all, but how many people would be willing to set it up just to see a link?

<comment><USER6> Just a crazy idea, when something like NaCl catches on perhaps gumroad could generate bitcoins client-side in lieu of payment?

<comment><USER5> [EDIT: the text below is correct, but a bit too snarky. My apologies.

Also, the site owner _could_ just trust the client to actually run his/her bitcoin-generating code for a couple of hours and send any generated coins - this should earn him/her ~$0.20/hour, rounded down because lots of people have crufty computers. Still not feasible, and generating bitcoins will only get harder in the future, but not as bad as I suggest below.]

Sure, if you're willing to leave your browser consuming 100% CPU for a couple of weeks. And if you're willing to pay the entire resulting 50 bitcoins (~$40-45) you generated (at the cost of ~$60 in electricty, I'd guess)[1], or trust the site to return you the rest. In either case, you'd need to trust the site code to tell you that it's generated a coin, instead of silently sending it back to the server and continuing to run.

At least, that's my understanding of how bitcoins work.

[1] Only GPU-based generation is currently profitable, and there's no way NaCl can be given full access to the GPU - GPUs typically have DMA access, so being able to run arbitrary code on them is more or less equivalent to kernel-level access. In theory, you could verify the GPU code - but that's an enormous job, and there are lots of GPUs that you'd need to check for security holes. And security was not design criterion #1 for these devices, I'd guess.

Something like DirectX/OpenGL access makes sense, but running crypto algorithms through OpenGL (instead of CUDA or the like) is probably infeasible.

<comment><USER6> Good points. I figured it was probably totally infeasible, thanks for filling me in on why.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> Interesting idea, but I see two main issues with this.

First, anyone who pays and gets to the resulting link can trivially share _that_ link; of course, you can always ask them nicely not to do so, and in some contexts that will work, but in general the security model just doesn't work unless you authenticate each paid user at the destination. You need to come up with an answer to this.

Second, if you market this as a link shortener which requires payment, I think you'll get backlash from people who currently use link shorteners to share links on Twitter and similar; from that perspective it feels like the kind of thing you'd see used by Twitter spammers/scammers. Suggested fix: flip it around, and present it as an astonishingly simple payment system based on URLs, which happens to behave like a shortener.

<comment><USER8> That second formulation is how I thought of it in the first place.

You could get around the link-sharing problem for those that wanted to avoid it by offering single-use URLs, and provide Gumroad either with a way of generating a new single-use URL for your resource, or a way to pull a new URL from your site. Both of these methods would require some degree of control over the resource, however (you wouldn't be able to do this for content hosted by third parties).

For those who aren't fussed about security, you could offer it as a really easy way to optionally pay for content - eg a rapid "Donate" method.

<comment><USER9> To address the first problem, you should offer a passive solution and not require the user to set up anything special in the way of single-use URLs. In fact, I assumed the issue of payers sharing the end-link was such an obvious problem that the service would have already addressed this and had it built-in by default (but of course, MVP/first-release, I understand).

The way I'd see it working is, I give Gumroad a link I want users to pay for, and Gumroad charges each user, serving up the content, but never sharing with them the link that I gave Gumroad. You could do this by fetching the content on the back end, and serving it up through Gumroad's own single-use URL.

<comment><USER8> Sure, that would make sense for content that could be so served (for example, the pencil icon used as the example here) - but not all content is like that. What about content you want people to interact with (a blog post on your site, a special beta registration form)? You also take on all the problems of becoming a content distributor rather than a link distributor.

<comment><USER9> I agree with everything you said. If this were my project, these are all problems I'd be thinking about and trying to address. Looks like you're on the right path ;-)

<comment><AUTHOR> I'm thinking about them hard. :)

</comment></comment></comment></comment></comment></comment><comment><USER10> Clickable: <https://gumroad.appspot.com/l/jxrvbk>

<comment><AUTHOR> Trying to sell the link to Gumroad for $100?! Stop trying to profit off of my work! :D

<comment><USER10> It's profit all the way down.

<comment><USER11> _"But I make a profit of three and a quarter cents an egg by selling them for four and a quarter cents an egg to the people in Malta I buy them from for seven cents an egg.

Of course, I don't make the profit. The syndicate makes the profit. And everybody has a share."_

\-- Milo Minderbinder, Catch 22

</comment></comment></comment></comment><comment><USER12> Traceback (most recent call last):

      File "/base/python_runtime/python_lib/versions/1/google/appengine/ext/webapp/__init__.py", line 634, in __call__
        handler.get(*groups)

      File "/base/data/home/apps/gumroad/1.349472656690944858/main.py", line 60, in get
        if is_logged_in():

      File "/base/data/home/apps/gumroad/1.349472656690944858/main.py", line 110, in is_logged_in
        s = sessions.Session()

      File "/base/data/home/apps/gumroad/1.349472656690944858/appengine_utilities/sessions.py", line 562, in __init__
        self.session = _AppEngineUtilities_Session.get_session(self)

      File "/base/data/home/apps/gumroad/1.349472656690944858/appengine_utilities/sessions.py", line 142, in get_session
        ds_session = db.get(str(session_key))

      File "/base/python_runtime/python_lib/versions/1/google/appengine/ext/db/__init__.py", line 1422, in get
        keys, multiple = datastore.NormalizeAndTypeCheckKeys(keys)

      File "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore.py", line 180, in NormalizeAndTypeCheckKeys
        keys = [_GetCompleteKeyOrError(key) for key in keys]

      File "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore.py", line 2339, in _GetCompleteKeyOrError
        key = Key(arg)

      File "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore_types.py", line 364, in __init__
        raise datastore_errors.BadKeyError('Invalid string key %s.' % encoded)

BadKeyError: Invalid string key agdndW1yb2FkciMLEhtfQXBwRW5naW5lVXRpbGl0aWVzX1Nlc3Npb24Y.

<comment><USER13> I got an error like that also when trying to log in.

</comment></comment><comment><USER14> Things you have to look at fast.

* Money laundering. Cap fees now.

* You are using Stripe, but you're still collecting CC data. Are you PCI compliant?

* Does Stripe allow you to do this? Really? Basically, you're acting as a third party processor, an IPSP. People can sell anything through your service (Think adult content)

I'm really interested if Stripe is aware of what you are doing and fine with it.

<comment><USER15> PCI compliance is only an issue if he's _storing_ CC data.

<comment><USER16> I'm no expert, but I don't think this is true. I've witnessed a few payment systems being implemented, and just having this data pass through your system you need to adhere to some compliance rules (which are softer vs. actually storing the data though).

<comment><USER17> Correct. We are doing a PCI compliance certification right now, for a service that does the same CC flow as this. We don't store, but just forward. But even that requires a PCI certification.

</comment></comment></comment></comment><comment><USER18> You have an XSS on the login form. I create a page which posts to the login page with the name

" onclick="alert('do evil here')" onfocus="alert('do evil here')" foo="

It errors out, and my javascript is now in the input box. They click the name and then it runs my javascript.

It's great you've escaped < and >, but you need to do more.

</comment><comment><USER19> As with many ideas I see floated and mvp'd on HN, I'm jealous. Great idea, good execution. I'd agree with others that the 30% is too high. 5-10% would be acceptable.

<comment><USER20> Why be jealous? He has no traction. Copy it and do it slightly better.

<comment><AUTHOR> I have 50,000 page-views worth of traction and over 1,000 users - many of them making real money. :)

Kidding aside, I dare you (not sarcastically, I would love to see another approach to the same problem).

<comment><USER19> I may do that, but perhaps focused on a particular niche. Thanks.

</comment></comment></comment></comment><comment><USER21> Seriously? I'm not sure I could take anyone seriously that tried to sell me a link of "value." Why not just share the link for free like people have been doing since the beginning of time?

Don't get me wrong. You did a great job getting this rolled out over a weekend and it looks nice. I must need some enlightening because I really don't get it.

<comment><USER22> Imagine you have a Fireworks iPhone mockup template.

Instead of setting up a store somewhere to list your ONE item, you put the template up on your website and link to it through gumroad.

Then, you give out the Gumroad link on Twitter: "Need a sweet Fireworks iPhone UI template? Buy it for a buck: gumroad.url"

Your twatting friends click it, give you a dollar, get redirected to your website. They download the template, you get a dollar - all in like 2 minutes while your oatmeal was cooking.

<comment><USER23> And 2 minutes later the "secret" link is shared on Twitter.

<comment><AUTHOR> I think people who use Gumroad won't really have that as a concern - but if enough people bring it up, I'll see what I can do about it!

<comment><USER5> For many of the things that people might want to do, a "patronage" model isn't so bad either: the creator demands $1000 for the work behind the link; people can leave an e-mail address and pay anything from $1 to the full remaining price, and will be notified as soon as the work is available.

<comment><USER24> I think this has tons of value, almost like a mini-kickstarter without the need to advertise for a kick for communities of people (forums, etc) who want new features or some kind of quick bit of work done.

</comment></comment></comment></comment></comment></comment><comment><USER25> Loving the simplicity of the idea. The simplicity is worth a higher cut (though maybe not 30% ;-)) and makes it a lot more attractive to use in small situations. One thing you need to beware of, though, is the filing requirements.. you might have to start issuing tons of 1099s and that process will cost you.

</comment><comment><USER26> If this becomes a high traffic site, it could really help fight internet piracy. If I have a high demand, hard to find video, I'm far more likely to try to sell it than just give it away. And even if I can't because the site is closely watched by the actual copywriter holders, the idea that money can be made off any online property can give internet knowledge and assets the feeling of physical worth, to the degree that people may grow hesitant to just give away their video and music files. It also has potential to detract from the information free-for-all of the internet, as people may also grow hesitant to share in general, but that would only be for sellable things, so blogs and general information are basically out. If successful, this site could make major change in the attitude of the internet. In essence, conflict exists between copyright holding companies, who believe their intellectual property should be paid for, and the general population of the internet, who freely share information constantly. This conflict could seriously benefit from a general shift toward the resounding feeling that information and online assets are worth something and should be bought and sold. That could be of serious detriment to the culture of the internet, but the communities could also gradually adjust. After all, the feeling that assets have monetary value is the way we live in the real world, its only a matter of time before the internet starts to follow.

</comment><comment><USER27> What do you plan on doing about fraud? Seems like it would be way too easy to move money around with stolen credit cards.

<comment><USER28> He's not doing the payment processing, Stripe is.

<comment><USER27> In the world of payments, that doesn't really matter at all. Payment processors can't afford to have high fraud % customers, so if fraud becomes a problem they'll just drop him.

</comment></comment></comment><comment><USER29> How does this work for art though? I mean you want to see the icon/graphic/design/whatever before you pay for it.

Also - once you've been redirected to the page, what's to stop you taking the link and sharing it yourself?

Also also: if I've got something to sell, can't I just bung it on ebay?

<comment><USER30> Thought of this too, I guess you can watermark images.

Not sure how you would sell JS scripts since showing a working demo would require the file to be accessible to the user.

<comment><USER31> That script you make is copyrighted, if they take it without paying you for it (if that is the deal), then they just broke the law.

<comment><USER32> Sure, but the question is how to make it more difficult.

</comment></comment></comment></comment><comment><USER33> This looks like a really expensive way to get Rick Roll'd :)

<comment><USER34> Yes, how _do_ you deal with the (hundreds, thousands, millions) of annoyed customers per day who were promised one thing but wound up paying for another?

This can't be a minor problem, either. At any given time the percentage of your users who are being ripped off by some nasty scam will be between 10% and 90%. You'll have to be _very_ careful about policing things, otherwise the first mention of your business in the media will be "gumroad enables porn bait-and-switch scammers".

</comment></comment><comment><USER35> Please put a video on the homepage. If I'm on the fence, I'd rather watch a video than create an account.

<comment><USER36> can I quote you?

</comment></comment><comment><USER37> If the payment fails, will you still redirect to the link?

If you only redirected based on successful payments, you could use this as a simpler paypal for charging clients on your site using unique gumroaded links.

<comment><AUTHOR> You only get redirected if your payment goes through. Yes, that is a potential use-case.

</comment></comment><comment><USER38> Is the redirect-link unique in any way? I mean.

If anyone buys the access to a a non-unique-link (ie: <http://mybook.com/book.pdf>), and then shares the redirected URL to a third person, this third person could load the link without paying, right?

<comment><AUTHOR> Yup. For now, there is no security built into the link once you get through that payment wall. I'm thinking about how to do that without hurting UX - though it's low on the priority list anyways.

</comment></comment><comment><USER39> I get a broken lock icon, and "Connection partially encrypted" message. You need to make sure all externally linked resources on the page use SSL. Specifically: change <http://fonts.googleapis.com/css?family=Cabin:regular,bold> to <https://..>.

<comment><AUTHOR> Thanks for the notice, I'll do that.

</comment></comment><comment><USER40> The copy on the re-direct page is bothering me a bit. Anyone else?

 _You're being shared Gumroad!_

With the "You're being shared". Sounds confusing.

<comment><USER41> "You got Gumroaded!" Wait, no. That sounds wrong for some reason.

</comment></comment><comment><USER42> Interesting concept -- how do you deal with the legalities?

If I buy something am I buying it from you or from the original owner?

How long do you hold onto the funds to deal with any potential chargebacks?

</comment><comment><USER43> This may just be the simplest way to sell digital goods.

I think all content should be uploaded to your servers otherwise if someone gets to the final link they can just send others to it.

</comment><comment><USER44> I like the simplicity of the home page, but I would want to see what a user would see when supplied with a gumroad'd link before singing up.

<comment><AUTHOR> Agreed. Added that to the to-do list.

</comment></comment><comment><USER45> I'm already giving this away for free with a PayPal donate link at <http://pickdropapp.com/> but what the hell: <http://gumroad.com/l/cvhhwi>

</comment><comment><USER46> Are you collecting taxes? if it's a company registered in the US

Also how do you deal with chargebacks?

</comment><comment><USER47> Traceback (most recent call last): File "/base/python_runtime/python_lib/versions/1/google/appengine/ext/webapp/__init__.py", line 634, in __call__ handler.get(*groups) File "/base/data/home/apps/gumroad/1.349472656690944858/main.py", line 60, in get if is_logged_in(): File "/base/data/home/apps/gumroad/1.349472656690944858/main.py", line 110, in is_logged_in s = sessions.Session() File "/base/data/home/apps/gumroad/1.349472656690944858/appengine_utilities/sessions.py", line 562, in __init__ self.session = _AppEngineUtilities_Session.get_session(self) File "/base/data/home/apps/gumroad/1.349472656690944858/appengine_utilities/sessions.py", line 142, in get_session ds_session = db.get(str(session_key)) File "/base/python_runtime/python_lib/versions/1/google/appengine/ext/db/__init__.py", line 1422, in get keys, multiple = datastore.NormalizeAndTypeCheckKeys(keys) File "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore.py", line 180, in NormalizeAndTypeCheckKeys keys = [_GetCompleteKeyOrError(key) for key in keys] File "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore.py", line 2339, in _GetCompleteKeyOrError key = Key(arg) File "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore_types.py", line 364, in __init__ raise datastore_errors.BadKeyError('Invalid string key %s.' % encoded) BadKeyError: Invalid string key agdndW1yb2FkciMLEhtfQXBwRW5naW5lVXRpbGl0aWVzX1Nlc3Npb24Y.

</comment><comment><USER48> Am I missing something or could you just employ a download method rather than link? Maybe something like how istockphoto does it. Although the link leads to a purchase terminal, if they make the purchase it would prompt a download rather than a link they could share.

Also link shorteners + asking for credit card information immediately can get iffy in terms of trust and fraud. I understand that it is an mvp though. Later you might be able to employ a buy credits system like istockphoto does.

</comment><comment><USER49> I really like you color pallette. How did you come up with it?

<comment><AUTHOR> I took it from Colorlovers. Here's a link: <http://www.colourlovers.com/palette/1473/Ocean_Five>

</comment></comment><comment><USER50> Traceback (most recent call last): File "/base/python_runtime/python_lib/versions/1/google/appengine/ext/webapp/__init__.py", line 636, in __call__ handler.post(*groups) File "/base/data/home/apps/gumroad/1.349498677539326613/main.py", line 292, in post db.delete(link) File "/base/python_runtime/python_lib/versions/1/google/appengine/ext/db/__init__.py", line 1491, in delete datastore.Delete(keys, config=config) File "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore.py", line 516, in Delete keys, multiple = NormalizeAndTypeCheckKeys(keys) File "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore.py", line 178, in NormalizeAndTypeCheckKeys keys, multiple = NormalizeAndTypeCheck(keys, (basestring, Entity, Key)) File "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore.py", line 157, in NormalizeAndTypeCheck (types, val, typename(val))) BadArgumentError: Expected one of (<type 'basestring'>, <class 'google.appengine.api.datastore.Entity'>, <class 'google.appengine.api.datastore_types.Key'>); received None (a NoneType).

</comment><comment><USER51> Seems good.

How long until exact clones appear? What makes GumRoad the micro-paywall of choice?

How long until shortened<\-->lengthened websites appear which reduces how many people pay up?

</comment><comment><USER52> You can tell clients to check the http referrer for your domain. That would (mostly) stop people from posting now-useless destination URLs online.

http referrers are easily spoofed, of course, but it'll be enough to prevent most people from sharing secret urls on twitter. You could also pivot and allow people to upload files to your own server, but that's a different story.

<comment><AUTHOR> That would hurt the UX. For example if someone gets the link to a blog-post- in-the-making they shouldn't have to go through Gumroad to access it every time.

<comment><USER7> Not bad to have the option, though.

</comment></comment></comment><comment><USER53> Brilliant little idea, I think the big selling point is speed and ease of use. I might create a similar product to this for BitBuffet.com (a similar file selling service I created), as I think the process can be further streamlined.

Digital sale processes still need streamlining for everyday users (especially one-off users) and I can see a service like this taking off.

</comment><comment><USER34> I'd work on the name. Gumroad? What does it mean?

To me it brings up an image of a road, covered with gum. I'm trying to get where I want to go, but there's all this gum on the road slowing me down. It's a huge and annoying obstacle. And _that_ is a bad mental image, given that what you're selling _is_ a sort of obstacle.

It's not too late for a different name.

<comment><USER54> Huh...I guess that makes more sense, but actually my first impression of the name was to think of Candyland. Like the Yellow Brick Road, but with gumdrops and such. Cheesy, but positive. I wonder which interpretation is more common?

</comment></comment><comment><USER55> Nice product!

Feature request: use the top half of the screen to show a preview of the linked page rendered as a PNG. Use the other half of the screen for soliciting payment. I want to know what I would get with the payment. How much of the target page is shown should of course be configurable by the page owner.

</comment><comment><USER56> First off, I like the idea, but there are some noticeable flaws, many which have been brought up.

One interesting one for me, which is more an oversight, is that anyone can make money off of the sale of a link. There is no way to validate that the person posting the link, is the owner of the content. So someone could sell links to a page on HN, Reddit, Techcrunch, etc. at no expense to them.

If this did occur, I think it would cause a quite negative view of Gumroad links, as being scammy. In which case, people would begin to avoid them, reducing their effectiveness as a possible sales medium. Without oversight, as to who is selling a link, this might end up smothering itself out.

<comment><USER57> While providing an authority model is often a great business, it's a fallacy to say that provenance is mandatory to be taken seriously. See: Twitter, eBay, 4chan, TechCrunch

</comment></comment><comment><USER58> <http://please.bitcoin.me/now/>

</comment><comment><USER59> I saw it mentioned here already, but the idea of a "Name your Price" option would be really cool. Just like how Bandcamp does it. I'm always more motivated to support artists that chose this option.

</comment><comment><USER60> What are your fees? Didn't see that anywhere on the homepage.

<comment><AUTHOR> Honestly, I'm not sure - hence them not being listed - but I think I'm going to go with 30%. And then for people making >$x a month dropping that in tiers. Thoughts?

<comment><USER60> At 30%, unless my product is pure profit I'm going to look elsewhere. A Paypal (or WePay!) buy now button isn't that hard to create after all...

<comment><USER61> Yeah - I'd rather try my luck at Kickstarter and pay their 5% fee and PayPal's 2.7%.

You'd have to write up some very specific usage scenarios that make that cut viable.

Apple's cut makes sense so far that you get some tangible advantages in terms of such things as exposure. You'll have to explain people what they _get_ for the 30% cut.

Right now, I'm unconvinced that you get 30%'s worth. But, on another note, it's probably always better to start at a high price and dial it down than to launch a product and increase the prices over time. People will be crying bait and switch - justifiably.

</comment></comment></comment></comment><comment><USER62> I've been thinking about this exact problem for a few weeks now. I have gone as far as buying a domain for it (epayfiles.com) and I just started coding. I think I'll continue on with my project I'll just focus on a different payment niche.

After doing some quick research I found five or six sites with similar ideas. Most of them focus on selling digital files not links. The link idea sounds novel. The presentation is also very clean. Looks good.

</comment><comment><USER63> There's some potential for gamification here. Here's a Gumroad URL which, when paid for, unlocks some kind of challenge that you must solve in order to find a new Gumroad URL. Which unlocks another challenge that leads to another Gumroad URL, continuing for n steps until you unlock the final reward. Each step costs less than a dollar.

How would this have played out if eg. Dropbox had run their challenge on top of Gumroad?

</comment><comment><USER40> Is this what you've been working on in SF, Sahil :) ?

<comment><AUTHOR> At least for the past two days, yup. Just a small part of the rest of my life though!

</comment></comment><comment><USER64> Seems cool. I wish you'd render the about text box for products with Markdown or something though so the links were clickable.

</comment><comment><USER65> I already dislike URL shorteners, there's no way I'm going to give my credit card info to one.

</comment><comment><USER66> If the value is zero the user is being redirected to home, after accessing the link url.

</comment><comment><USER67> I like it, there's a lot of functionality missing, as you said but tons of possibilities.

I'd like to see a "pay as much as you'd like" feature, where you can set a minimum amount (like radiohead and girl talk do) but still allow them to pay more.

</comment><comment><USER68> Why wouldn't stripe just implement this themselves? Since their payment processing service (and API?) is 99% of the project, seems like they'd make their own and cut you off if this gained any traction.

<comment><AUTHOR> It's not 99% of the project, it's one line of code (among over 2,000).

<comment><USER7> _One_? That sounds like a rather awesome API, unless you just redirect to a payment processing system over on their site. Mind sharing the one line of code? :)

</comment></comment></comment><comment><USER69> This is my daily fail: [http://potomak.tumblr.com/post/4361901296/developer- business...](http://potomak.tumblr.com/post/4361901296/developer-businessman)

Developer ≠ Businessman

</comment><comment><USER70> I think it's a great idea, and really well implemented so far.

Best of luck with it!

</comment><comment><USER71> Just a caution, if you are taking in money via paypal and then paying out via paypal, paypal will probably shut you down within a month. They don't like competition.

</comment><comment><USER72> i love the idea, i hate the new "We have a tiered system for pricing:" basically it says: if you earn less, we will take even more. so basically if - lets say - earn 2 dollars (casual user who sold a psd template for 1$) this service now takes 2$ - 2 _30c = 1.40$ - (1.40$_ 0.3) = 98c

this tool should encourage casual use and it makes a perfectly simple product complicated.

please overthink your pricing-strategy. make it as simple as possible, iterate from there.

</comment><comment><USER73> I saw this post the other day, then came across Pulley. Is there a difference? <http://pulleyapp.com/>

</comment><comment><USER16> sahillavingia, your personal site looks awesome too! <http://sahillavingia.com/>

</comment><comment><USER74> How do I know that, when I pay, I am actually getting what I am paying for? How do you handle chargebacks etc..

</comment><comment><USER75> Really neat way to sell vulnerabilities.

</comment><comment><USER76> Great idea. Your email address matching is case sensitive, you might want to fix that.

</comment><comment><USER77> Well done this is brilliant.

</comment><comment><USER78> please tell us when the first (real) vc are knocking on your door ... this is just awesome and has more potential then the most startups covered by techcrunch and co

</comment><comment><USER79> Nice - how about this as a feature: # of downloads allowed. This would allow people to sell just 1 copy or set up something like a groupon-esque clone. First 50 people get 50% off. Then after 50 people say you're too late. Just an idea.

<comment><USER80> I really like this idea, especially for art. It solves the "what if someone just passes the final link around" problem because if you're getting 1 of 25 copies of something you're less likely to go out of your way to reduce the rarity of the item you bought.

<comment><USER79> Expanding on that if there is a limited # you could choose to list # left to create a sense of urgency or keep it hidden and mysterious. Good luck!

</comment></comment></comment><comment><USER81> So it's funny that this happens today: <http://news.ycombinator.com/item?id=2407969>

</comment><comment><USER82> There is no way to stop re-selling of the content once somebody has bought it short of implementing some horrendous DRM system.</comment>


Real-World Analytics: Shops secretly track customers via mobile phone - <AUTHOR> http://technology.timesonline.co.uk/tol/news/tech_and_web/article3945496.ece

<comment><USER2> I like all the protesting that they can't track the IMEI code back to a person. They either don't want to, or they need better nerds.

With the {IMEI,time,location} that this produces and the {store,creditcard,time} that the credit card machines produce I could have reasonably reliable {IMEI,creditcard} mappings in two transactions, very reliable in three. (except for your friends traveling with you, I'll have to wait for you to shop without them to separate your identities)

</comment><comment><USER3> It seems that phones also transmit a phone number along with the IMEI code; and a phone number certainly isn't anonymous.

Discussion is in the comments here: [http://neosmart.net/blog/2008/mapping- computer-techniques-to...](http://neosmart.net/blog/2008/mapping-computer- techniques-to-the-real-world/)

</comment><comment><USER4> This has been happening for some time, and you can build your own using gnuRadio if you wish to give it a try

</comment><comment><USER5> I love how people feel that collecting data they're broadcasting into the open with no expectation of privacy is a privacy violation.

Think of it as your neighbors recording when the lights in your house are on or off. It may be weird, but it's hardly wrong.

</comment><comment><USER6> "should the data fall into the wrong hands."

What sort of wrong hands could make use of data like this??? They would know that a certain IMEI code was in a certain shopping center at a certain time :/ wow.</comment>


Matrix – An Open Standard for Decentralised Persistent Communication - <AUTHOR> http://matrix.org/ <comment><USER4> Very interesting. Lots of questions, but I'll avoid those that are listed but not yet answered in the FAQ.

How does Matrix deal with netsplits and partial-netsplits?

How are highly diverged histories (e.g. a long netsplit in an active room) supposed to be merged?

Does the protocol require O(N^2) connections for N users? (The number of users in some IRC rooms is measured in thousands.) Can it be more efficient?

How are rooms administered? E.g. how is it decided that someone is allowed in a room? That's easy with highly trusted rooms with personal acquaintances, but what about more public rooms like programming help or computer talk?

<comment><USER5> > How does Matrix deal with netsplits and partial-netsplits?

> How are highly diverged histories (e.g. a long netsplit in an active room) > supposed to be merged?

So the cool thing with the federation in matrix is that all the messages (and state changes like room memberships) are part of a directed acyclic graph (DAG), so any new messages that are sent reference the previous ones. (Very much like git). That way a server can tell if it is missing any messages as long as it can talk to _a_ server in the room. Since everything is signed by the originating servers, servers can pull in missing messages from third parties! Thus partial-netsplits are fine, as all the messages will eventually propagate through to all servers :)

When a full netsplit happens you effectively get two separate branches in the graph, each group of servers happily talking to each other. When a netsplit is resolved, one of the servers will realise they can talk to one of the other servers, at which point one of the them will send an event that references both branches (in effect merging them). All the other servers will then realise what they are missing and pull the branches in. At that point a certain amount of state resolution needs to happen (e.g. if people joined and left on the different branches) to ensure that all the servers have a consistent view of the state of the room.

The really difficult problem we've found is how you communicate to the clients about the netsplits, and how the clients should display the netsplits (although this is more of a UX issue, but still important). Since the messages in the room are stored as a DAG, the servers can see what messages were part of which netsplit and so that information can be made available to the clients.

> Does the protocol require O(N^2) connections for N users? (The number of > users in some IRC rooms is measured in thousands.) Can it be more efficient?

Currently the protocol uses full mesh to distribute the messages to all the servers (which in practice are going to be fewer than the number of users in the channel), though since it uses HTTP the servers don't need to maintain active connections to all other servers. We really want to come up with new distribution models for really large rooms at some point, but we haven't quite gotten that far yet :)

> How are rooms administered?

The user that created the room gets admin rights to the room and given a "power level". The admin can set the power level required to do different things, (e.g. kick, ban, set the name of the room etc), as well as whether you need an invite to join the room or not. They can also grant (and revoke) power levels to other members of the room. Now, if a remote server intentionally ignores these rules then other servers in the room will simply not accept the dodgy actions. All actions, whether message sending or banning someone requires the server be able to _prove_ that they had permission to do that by supplying a list of events along the lines: "I can ban because I have power level X, which was assigned by Y, who could do that because...".

(I'm part of the matrix team ftr.)

</comment></comment><comment><USER6> I think rather then federation people need real P2P systems and not only clients to a server. Specially I don't think that heavy relying on HTTP makes sense here - in addition it implies that the encryption you get is SSL, which is awkward. Things like GnuNet are of course not ready, but as you can see with people using Tox right now for communication, P2P networks allow to start a new design with respect to a good cryption model and methods improving anonymity of communication flows.

<comment><USER7> A server can do a lot for you that a standalone client can't. It's a machine that's always on, easy to back up, lets users communicate in real time, and the coordination of different client devices per account comes practically for free.

I think one of the reasons federated systems (which once were the backbone of the internet) are being phased out while the huge monoliths like Facebook are winning is that, while people _do_ want a federated alternative, they want this alternative to be philosophically pure in a way that makes the end user experience untenable.

I'm building an open source distributed social network quite similar to this Matrix thing, actually. It's simple, scalable, and it works. It provides a good user experience, too. But fellow geeks tend to _hate_ it. JSON over SSL? Too simplistic. ' _We want a VM that runs inside a JavaScript engine which implements its own crypto and _true_ P2P, nothing else will do._ '

The trouble is we do know how to make simple and "awkward" solutions work quite well, whereas I have yet to see a "pure" option I'd want to use myself. Of course, that may be personal preference in the end, but I'm kind of hoping I'm not alone.

<comment><USER5> Multiple device support and history synchronization between devices really are table stakes to me, especially since I tend to spend a lot of time checking messages and chatting from mobile devices these days..

That distributed social network thing sounds quite exciting, and very much in a similar vein as Matrix. Does it have a website/github repo yet?

We've definitely found its not always easy to balance a philosophically pure/technically nice solution with one that actually has a usable UX. Although it sometimes seems that half the battle is figuring out what actually is a usable UX...

<comment><USER7> > Multiple device support and history synchronization between devices really > are table stakes to me

I know where you're coming from.

We're working (well, it's just two guys for the moment) on the first version and we're planning to launch for early feedback soon. I'll be posting it as a Show HN, but in case it gets buried I can put you on our notify list - <USER2> shoot me an email.

</comment></comment></comment></comment><comment><USER8> Alright, how is this different from the other attempts at this type of server- based system? And how is this better than Tox, which is P2P?

<comment><USER9> I'm confused as to how it's similar to Tox. Matrix seems to be a server with an API that allows you to send and subscribe to messages. This would be useful for a software engineer working with M2M communication. Unless I'm looking at the wrong `Tox`, it seems to be a P2P IM client. These seem like completely separate domains, right?

<comment><USER10> Matrix is basically an eventually consistent object database with open federation and pubsub. It's optimised for messaging at the moment - you can use it for group chat, or WebRTC signalling, or M2M/IOT stuff, or anywhere else you want to pubsub data and keep a history. The similarity with Tox is that Matrix can implement a chat system that looks like Tox. The architectures are completely different though: Tox is a big distributed hashtable smeared over lots of peers; Matrix is client/server with synchronisation between te servers. (disclaimer: Matrix is my fault)

</comment></comment></comment><comment><USER11> This is absolutely the type of system I've been hoping for for quite a while. I even started drafting up a spec to build it. I wanted a federated, http based message passing pub/sub type system with device synchronization - <USER3> (here's the kicker) - encryption optional.

So why don't I want encryption? Simple, my intended use is in amateur radio, where encryption is in fact restricted (basically, you can only use it to control a satellite).

In amateur radio, we have been developing this mesh network (basically wifi mesh, but we can use much higher power and alternate, non-line-of-sight frequencies like 440Mhz). With the HSMM-Mesh system, we have built in dhcp, dns, ability to advertise services (web, irc, etc) on systems that are usually completely isolated from the Internet at large. We run this on re-purposed routers, laptops, raspberry pis, etc. So you can setup an IRC, FTP, or web server on a pi, someone else can bring a node up within range of your wireless signal, see your node, get a list of services you offer, and use them.

An issue with this is that you want to make multiple "field nodes" and deploy them

So matrix would work really well here. Since each node has its own DNS name (based on our call sign), you could run a matrix server, set people up with the clients, and if we learn of another matrix server on the mesh, federate with it. The two matrixes become consistent eventually. If we bring a node (these would all be battery powered portable) into range of a more permanent fixed station, all the days activity could end up on that fixed station. The fixed station could federate with an Internet instance as well (which would require more extensive validation to ensure users are licensed operators).

A few issues would be user registration - we'd have to disable verification in the field as there won't be email. I don't think we'll have username conflicts. USER1@SERVER1 won't conflict with USER1@SERVER2. Since all users are government issued call signs, identity will be consistent across each matrix server.

<comment><USER11> I also wanted to point out that it would be easy to use something like twisted to write an IRC or XMPP gateway to a specific matrix server. Then you can utilize a common IRC or XMPP client (though message ordering might be a major issue in an occasionally connected environment).

<comment><USER10> This would be a really cool use for Matrix - the eventual consistency and offline operation stuff is a perfect fit :D

You _don 't_ need an email address to sign up currently - the way it works is that it's up to the homeserver to decide how to validate new users (if at all). So Matrix.org uses a CAPTCHA to check you're human, but otherwise just sends a username & password. We also let you optionally specify a mail address, mainly just to prove that we do support validating 3rd party IDs like email (and in future MSISDNs and other IDs).

For gatewaying, the main thing we've been missing is an Application Service (AS) API on Matrix which lets your gateway masquerade multiple users & rooms/channels from the remote protocol. Currently you can write a back-to- back bot which creates, per user, an IRC user on the IRC network and a Matrix user on the Matrix network and bridges them together - this is how the current Matrix<->IRC bridge works. This sucks if you want to easily project hundreds of users & channels from IRC into Matrix and vice versa, though - you need better server support, a bit like IRC Services' architecture.

The good news is that this is _very_ nearly implemented - we got our first AS up and running a few hours ago (it currently just logs traffic rather than bridging it anywhere). It's all happening on the application-services branch of [https://github.com/matrix-org/synapse](https://github.com/matrix- org/synapse) and the doc is at [https://github.com/matrix-org/matrix- doc/blob/application-se...](https://github.com/matrix-org/matrix- doc/blob/application-services/drafts/application_services.rst) and [https://github.com/matrix-org/matrix-doc/blob/as-http- api/dr...](https://github.com/matrix-org/matrix-doc/blob/as-http- api/drafts/as-http-api.rst) if you're interested.

Twisted is probably overkill for many ASes, but it could be a great way to do the XMPP & IRC bridging in future.

</comment></comment></comment><comment><USER12> Interesting! How does Matrix relate to red#matrix [1] and the Zot protocol? Not asking because both projects contain the word "matrix". Both projects seem to overlap. Would like to know more about how they differ and how they relate.

[1] [http://redmatrix.me/](http://redmatrix.me/)

<comment><USER10> There is no link between RedMatrix and Matrix.org - the fact that both have Matrix in the name is total coincidence. On the Matrix.org side, we came across RedMatrix for the first time a few months ago when stumbling across [http://lists.w3.org/Archives/Public/public- fedsocweb/2013May...](http://lists.w3.org/Archives/Public/public- fedsocweb/2013May/0061.html) in Google, which then linked from Friendica/Red to RedMatrix.

I've never played with Friendica/Red/RedMatrix/Zot, but from what I can see, it's more about federated blogging/social networking than messaging or pure JSON synchronisation like Matrix. Architecturally I'm not sure how they compare - I only just found [https://github.com/friendica/red/wiki/zot;](https://github.com/friendica/red/wiki/zot;) we'll have a read and see what the difference is.

Something we're very keen to do with Matrix.org is to build as many gateways and bridges through to other comms ecosystems as possible - so the fact that both Matrix.org & RedMatrix (& Diaspora & Identi.ca & all the others) are operating in a similar space isn't at all a problem - so long as they all talk to each other. It'd be a bit embarrassing if we were building federated communication systems which couldn't gateway to each other!

</comment></comment><comment><USER13> I will be the cynic and say it right away:

this is all good and dandy like jabber was. Then someone like google will provide a massive, free*, always-on server. take control of everything because it will have all the users. and dictate when features are in or not (e.g. jabber federation)

Or is this harder to happen with matrix?

<comment><USER10> Yes, it's deliberately much harder for this failure mode to happen:

1\. Matrix's baseline featureset is much more comprehensive than XMPP and doesn't yet support API extensions; only datatype extensions. So for a Google to become the defacto implementation and then start lobotomising the featureset they really would not be speaking Matrix at all any more.

2\. Federation is completely fundamental to Matrix. All rooms are distributed over all participating servers with no single points of control or failure. So rooms and the network will always live on in other servers, even if a big player becomes a default provider.

<comment><USER13> thanks for the explanation. but can't they encapsulate proprietary extensions in the message data itself?

</comment></comment></comment><comment><USER14> It's interesting but I feel like it's redundant with XMPP.

I think we don't give enough credit / importance to XMPP because it's not "brand new", it's not what the cool kids use.

How can we make XMPP cool again ?

<comment><USER10> XMPP and Matrix are fundamentally different things. XMPP is all about message passing. Matrix is all about state synchronisation. In many ways Matrix is more like an eventually consistent distributed DB like Cassandra or Riak, albeit optimised for storing persistent messages and with open federation (anyone can spin up a node and join the DB) and an HTTP/JSON API.

So: if you want decentralised message history as a first class citizen, use Matrix. It's not just for group chat; it's for any data.

If you want lower-latency message passing with history as an optional extra, use XMPP.

In terms of how to make XMPP cool again - projects like XMPP-FTW and Buddycloud and FMUC are pretty cool :)

</comment></comment><comment><USER15> Interesting - Would be keen on hearing more around it's end-to-end encryption and OTR like capabilities though?

<comment><USER5> End to end encryption is probably one of the last big things we've yet to fully tackle, unfortunately. Though hopefully we'll fully begin to start spec'ing that sometime soon!

One of the major things we want is the ability for e2e encrypted messages to still be readable from all of your devices, which is kind of incompatible with OTR. Saying that, people have been talking about building OTR on top of Matrx; either by embedding OTR messages directly in the message JSON or using Matrix to negotiate a data channel with something like webrtc.

<comment><USER10> We've also been looking at Axolotl as a better-than-OTR for the E2E crypto. But nothing is set in stone yet.

<comment><USER10> ...where "We" is the Matrix team :)</comment></comment></comment></comment>


Dell-EMC to Lay Off 3,000 US Workers After Requesting 5,000 H-1B Visas - <AUTHOR> http://wolfstreet.com/2016/09/09/dell-emc-lay-off-2000-3000-u-s-workers-after-requesting-5000-h1b-visas-green-cards-to-import-foreign-workers/ <comment><USER2> Employees aren't fungible though. You can't convert an accountant into an engineer. Or a marketer to an engineer. Or a recruiter to an engineer.

But sensationalism and click bait sells more ad impressions so let's play that up as much as possible.

<comment><USER3> And the last thing you need is those recruiters finding qualified employees in the US when you hire by h1..

I find that companies are very much opposed to seriously finding those matches where the employees are convertable since longterm employees cost twice as much as the untrained new hire in a role that now uses half their abilities. Further, if they are "certified" as competent in both fields instead of eliminated from the market as tainted goods, they can be snatched by better managed rivals who know how to get full value of a programmer-accountant instead of paying for both skillsets and not being competent to consistently manage profit from either one.

401k plans managed fairness by making sure your top and lowest employees got reasonably comparable benefits. It helped, but also lead to outsourcing the low roles. In this case, I think companies should be limited to h1s that cost more than the greater of: the average inflation adjusted salary they've laid off, the average salary they still have and the average market salary for the specific role. If that's too expensive for them, maybe its fine to let them workout their problems without crying about the labor market not matching their inconsistent needs.

</comment></comment><comment><USER4> Correlation doesn't imply causation.

Much as I loathe companies that do this sort of thing, I read this article as being not much better than link bait. Though doubtless there will be further layoffs, these seem to be finance, supply chain and a smattering of marketing. None of which are very good fits for H1B employees. I'm guessing most of the H1B applications are for the usual knucklehead services reqs.

</comment><comment><USER5> Isn't this exactly not what H1B is supposed to be used for? And isn't this against the law already?

<comment><USER6> I have no confidence that our "monetrocracy" (legalized bribery, money=speech, etc.) will ever do anything ever again to penalize such chintzy corporate nastiness in a substantial manner.

However, all is not lost: one can look at such corporate actions as a financial signal that they are on the path to decline (e.g. IBM). Their next acts will likely comprise of executive bonuses, more layoffs, more employee churn, reduced quality, customer losses, and opportunities for new and interesting companies that are interested in ability instead of financial engineering. Depending on the horizon and personal wealth, this can serve as an opportunity to short such stocks.

<comment><USER7> Is "plutocracy" the word you're looking for.

<comment><USER6> I think I meant monetocracy: [http://www.urbandictionary.com/define.php?term=Monetocracy](http://www.urbandictionary.com/define.php?term=Monetocracy) , [https://votesmart.org/public-statement/1043156/the-super- pac...](https://votesmart.org/public-statement/1043156/the-super-pac-welcome- to-monetocracy) . I thought I was guilty of a neologism but apparently the term has been in use since 2012 afaict.

</comment></comment></comment></comment><comment><USER8> To Dell

[http://imgur.com/RqPywQR](http://imgur.com/RqPywQR)</comment>


The Dark Side of Expertise - <AUTHOR> https://lwn.net/Articles/809556/ <comment><USER2> > They then told the students to go up the hallway to a different room where > there would be another test. What the students didn't know was that the test > was actually in the hallway; the time it took each participant to walk down > the hall was measured. It turned out that the students who had been exposed > to the "elderly words" walked more slowly down the hall. Attendees might be > inclined to call that "absolute crap", Brady suggested, but it is not, it is > repeatable and even has a name, "the Florida effect", because Florida was > used as one of the words associated with the elderly.

I haven't ready widely on this, but from what little I have, most attempts at reproducing this and other priming experiments have failed.

(see, e.g., [https://replicationindex.com/2017/02/02/reconstruction- of-a-...](https://replicationindex.com/2017/02/02/reconstruction-of-a-train- wreck-how-priming-research-went-of-the-rails/), [https://replicationindex.com/category/priming/](https://replicationindex.com/category/priming/) and [https://www.discovermagazine.com/mind/reproducibility- crisis...](https://www.discovermagazine.com/mind/reproducibility-crisis-the- plot-thickens))

<comment><USER3> I postulate that if this is a true cause/effect it depends on words having a strong association to the intended concept, and that concept being significant to the individuals.

Further, I would postulate that the selection of study participants at that time, and the construction of the test, were very well matched. Today there is probably greater cultural diversity and comingling, and may also there may be less unconscious association of those words to slow.

</comment></comment><comment><USER4> This was pretty ramble-y and pulled in some pretty unrelated examples.

* We never get a clear answer for why the Civic Center Engineers got the inputs wrong, so we can't conclude that it was because of their expertise.

* With the firefighters, there's a pretty easy proximal explanation, which again is not their expertise misleading them: panic. If anything, the solution to the problem shows that expertise was the solution to the problem, not the cause of it: by adding running without packs to their expertise in a concrete way, they were able to override panic.

* With the priming examples, I can see how this might be related, but the only example which actually involves expertise leading them astray is the baseball example. But this priming research, contrary to what's claimed in the article, _isn 't_ reproduce-able. And even if it were, these sorts of lateral thinking exercises have pretty limited applicability: detectives or theoretical physicists use a high degree of lateral thinking, but many careers don't, and I didn't get those examples from the article, I had to come up with them myself: that hardly speaks to this being an insightful article. And ultimately, it's unclear whether expertise leads detectives or theoretical physicists astray: surely part of gaining expertise in a field that requires a lot of lateral thinking involves building the skill of putting aside preconceptions. Again, I don't think we can conclude that expertise is the problem: it may be the solution.

Overall, this topic could be interesting, but this isn't an insightful article on it.

<comment><USER5> You are entirely missing the point in your first two points:

* The issue here isn't that the inputs were wrong, it's that the experts could not (or would not, if you don't want to be generous) accept that the structure was under-strength in spite of multiple reports; the believed their calculations rather than their lying eyes.

* There is no particular evidence that the firefighters panicked. Whether or not they did, though, they did what their training led them to believe was their only choice: keep their equipment and try to reach the top of the ridge. The foreman was the only one to realize either that the training wasn't going to work or that they had another option.

Do you have a great deal of expertise in this area?

<comment><USER4> > The issue here isn't that the inputs were wrong, it's that the experts could > not (or would not, if you don't want to be generous) accept that the > structure was under-strength in spite of multiple reports; the believed > their calculations rather than their lying eyes.

How does this support the conclusion that they were misled by their expertise? There are many possible explanations here.

> There is no particular evidence that the firefighters panicked. Whether or > not they did, though, they did what their training led them to believe was > their only choice: keep their equipment and try to reach the top of the > ridge. The foreman was the only one to realize either that the training > wasn't going to work or that they had another option.

There is no particular evidence that the firefighters were misled by their expertise, either.

If anything wasn't the foreman's realization arguably due to his superior expertise?

> Do you have a great deal of expertise in this area?

In the area of basic logic, such as figuring out whether evidence supports conclusions? I suppose you could say I do, although I wouldn't claim anything special.

</comment></comment></comment><comment><USER6> > "the Florida effect"

This 1996 study by John Bargh, using only 30 psychology undergraduates as test subjects, is now more known as the prime example of bad psychology, done with too small sample size and dubious statistical methods. This study is at the very center of the replication crisis in psychology. That the conference presenter has not followed at all what has happened in psychology in the past 8 years, erodes the scientific credibility of the presentation.

[https://replicationindex.com/2017/02/02/reconstruction- of-a-...](https://replicationindex.com/2017/02/02/reconstruction-of-a-train- wreck-how-priming-research-went-of-the-rails/)

[https://www.nationalgeographic.com/science/phenomena/2012/03...](https://www.nationalgeographic.com/science/phenomena/2012/03/10/failed- replication-bargh-psychology-study-doyen/)

[https://replicationindex.com/2019/03/17/raudit- bargh/](https://replicationindex.com/2019/03/17/raudit-bargh/)

[https://www.nature.com/news/disputed-results-a-fresh-blow- fo...](https://www.nature.com/news/disputed-results-a-fresh-blow-for-social- psychology-1.12902)

[https://www.nature.com/news/nobel-laureate-challenges- psycho...](https://www.nature.com/news/nobel-laureate-challenges- psychologists-to-clean-up-their-act-1.11535)

[https://www.nature.com/articles/d41586-019-03755-2](https://www.nature.com/articles/d41586-019-03755-2)

</comment><comment><USER7> Priming with respect to the Florida effect is a famously not replicable result. It's not a real effect. I'm more sympathetic to the word game example, yet it's not obvious how that translates to anything beyond.

With respect to the Hartford Civic Center, as always, it's a little more complicated than that. Yes the architects stood by their calculations, but this was more of a process issue than hubris. Despite the new techniques used, the plans were subject to peer review. Additionally the construction was not fully according to plan. Weaker struts were actually used than called for in the design, and that's on the construction manager rather than the architect.

<comment><USER8> > Weaker struts were actually used than called for in the design, and that's > on the construction manager rather than the architect.

I was wondering if something like that was the case. It's common practice among structural engineers that they will not inspect the building because then they are liable if they don't catch deviations in construction from what they made calculations for.

</comment></comment><comment><USER9> The civic center arena roof collapse is similar to the FIU pedestrian bridge collapse in that the engineers trusted their calculations over physical evidence of imminent failure:

> At 9 a.m. on March 15, a university employee heard a loud "whip cracking" > sound while under the bridge span, waiting for a red traffic light. At the > same time, the design-build team met for about two hours at the construction > site to discuss the cracks discovered on March 13. Representatives from both > FIU and FDOT were present. The FIGG lead engineer's conclusions were that > the structural integrity of the bridge was not compromised and that there > were no safety concerns raised by the presence of the crack.

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

Fortunately for NYC, when William LeMessurier received a phone call about Citicorp Center from a student, he went back and re-ran some calculations and realized that quartering winds would put his building under more stress than he originally realized. But no harm, that would be handled by the extra safety factor built into his calculations. Unless it turned out other changes had been made during construction he wasn't originally aware of. Well, I won't give away the whole story:

[http://people.duke.edu/~hpgavin/cee421/citicorp1.htm](http://people.duke.edu/~hpgavin/cee421/citicorp1.htm)

[http://www.engineersjournal.ie/2015/12/08/citicorp-centre- to...](http://www.engineersjournal.ie/2015/12/08/citicorp-centre-tower- failure-averted/)

</comment><comment><USER10> I was glad to see that the comments on the webpage provided a link ([https://replicationindex.com/2017/02/02/reconstruction- of-a-...](https://replicationindex.com/2017/02/02/reconstruction-of-a-train- wreck-how-priming-research-went-of-the-rails/)) to a summary of how priming research has been cast into doubt in recent years. Any talk, article, or premise that uses priming experiments to explain something, is a red flag for me. I'm not saying none of it really works, but I am saying that it is clear that something more complex is going on than we think, and many of the priming experiments, at a minimum, have been misinterpreted (and in some cases are just totally unreplicable).

</comment><comment><USER11> I don't buy this headline at all, the author does not prove there are actual experts behind this story at all...

The primary story used here is that a sagging arena roof was consistently deemed safe by "engineers" (no proof of expertise provided) based upon their calculations...and this is somehow a "dark side" of expertise? It reads much more like ineptitude; that'd be like any coder here constantly ignoring terrible performance and numerous bugs and claiming their architecture is just fine.

<comment><USER12> There's also an unexplained leap from "the calculations are correct" to "we should proceed as planned even though it's sagging when it shouldn't".

Even if the engineers were infinitely arrogant and assumed nothing could possibly be wrong with the design, you'd expect them to react by saying "you must be building it wrong or using substandard materials", or something.

<comment><USER4> This is the same annoying problem I found with Malcolm Gladwell's _Blink_. He draws this conclusion that we can trust our first impressions, but it's really unclear how he comes to that conclusion: some of his evidence comes to no conclusion, and some of it directly contradicts that conclusion.

</comment></comment></comment><comment><USER13> This is a write-up of a pseudoscience gobbledygook just-so stories that don't do justice to the complexities of the catastrophes they draw trite morals from.

Here's a more thoughtful write up of the Civic center collapse, attributed largely to a large project with diffusion of responsibility and no one empowered the fix the problems they were held responsible for. [https://eng- resources.uncc.edu/failurecasestudies/building-f...](https://eng- resources.uncc.edu/failurecasestudies/building-failure-cases/hartford-civic- center/)

</comment><comment><USER14> Just another study about expertise and how it can maybe not be beneficial:

[https://www.bmj.com/content/357/bmj.j1797](https://www.bmj.com/content/357/bmj.j1797)

From "Physician age and outcomes in elderly patients in hospital in the US: observational study":

> Physicians' skills, however, can also become outdated as scientific > knowledge, technology, and clinical guidelines change. Incorporating these > changes into clinical practice is time consuming and can at times be > overwhelming. Interest in how quality of care evolves over a physician's > career has revived in recent years, with debates over how best to structure > programs for continuing medical education, including recent controversy in > the US regarding maintenance of certification programs.

> Within the same hospital, patients treated by older physicians had higher > mortality than patients cared for by younger physicians, except those > physicians treating high volumes of patients.

Basically, expertise can change, and if you don't keep up, you may be following outdated advice (which might not useful or even possibly harmful). I feel like the "dropping your equipment" is a part of this. You need to know the right tool for the right job, and sometimes doing the same thing for years might lead you down the wrong path.

<comment><USER15> >I feel like the "dropping your equipment" is a part of this. You need to know the right tool for the right job, and sometimes doing the same thing for years might lead you down the wrong path.

This happened at my last job. The company I worked for hadn't really changed their methods for about 7 years. Jobs went slow, we worked ridiculous amounts of overtime and mistakes were a regular part of the job. Over the years I worked there, I went through everything, replaced a few processes, convinced the owner to get newer more efficent tools and in the end, cut down the amount of overtime we worked to almost nothing, reduced actual human operater times on our machines from about 2-3 hours per run to 20 minutes, and reduced mistakes and error from once a week or so to once in a blue moon.

The thing is, I didn't do anything amazing or groundbreaking, they could have been operating that way for longer, they'd just found something that had worked and never bothered to try and improve their system. I was left alone for a few years and given free reign to do pretty much whatever I wanted, I got sick of being overworked, so I started figuring out and changing whatever I could to make things quicker, easier and better and it really didn't take much in the end to make a drastic improvement.

</comment></comment><comment><USER16> TBH, if you gave me the list "dark," "shot," and "sun" I'm not sure I'd ever think of "glasses" as a word that went with all three, since I still don't really know what dark glasses are. I guess like dark sunglasses? Or maybe they mean "through a glass darkly"? Priming is a real effect, but that example of priming seems like it was poorly selected.

<comment><USER4> > Priming is a real effect, but that example of priming seems like it was > poorly selected.

Except maybe it's not even a real effect: [https://replicationindex.com/2017/02/02/reconstruction- of-a-...](https://replicationindex.com/2017/02/02/reconstruction-of-a-train- wreck-how-priming-research-went-of-the-rails/)

<comment><USER16> Interesting! Thanks.

</comment></comment></comment><comment><USER17> A really entertaining read, even if I am left wondering how much of the "Florida effect" stands up in the post reproducibility crisis times. And would have liked more details on the calculation failures. I would guess that there was perhaps less of a paycological bias and not a case of "you spend a large amount on a computer, if the calculations are wrong you are fired" type situation.

I've seen a lot of projects like this where pressure is built on project leads for the chosen solution to be correct and not just for the goal to be reached, which means you end up not looking at obvious alternatives because even if that solves the project "your solution failed".

Does anyone know of similar stories or books that deal with engineering failures from a human psychology view?

Personally I'm reminded of the coverage of the Challanger disaster in "Ehat do you care what other people think" by Richard Feynman, which I can highly recommend reading if you haven't already.

</comment><comment><USER18> This illogical talk is because of "Thinking, Fast and Slow", Chapter 4, which Daniel Kahneman has since questioned.

[http://www.decisionsciencenews.com/2012/10/05/kahneman-on- th...](http://www.decisionsciencenews.com/2012/10/05/kahneman-on-the-storm-of- doubts-surrounding-social-priming-research/)

USCSB has great work place accident round ups (CGI, no gore). Of course Expertise is what makes the workplace safer, it has no dark side.

Here's Murphy's law (If it's possible for it to happen, given enough time it will, so don't allow it to physically happen wherever possible over processes)

[https://www.youtube.com/watch?v=Tflm9mttAAI](https://www.youtube.com/watch?v=Tflm9mttAAI)

</comment><comment><USER19> A eerily similar case of an eruptive fire killing firefighters happened not so long ago (in 2007) in Croatia.[1]

In this case it was most likely that the group of fire fighters did not have time to reach a safety zone and escape. [2]

[1] [https://en.wikipedia.org/wiki/2007_Croatian_coast_fires#Korn...](https://en.wikipedia.org/wiki/2007_Croatian_coast_fires#Kornati_tragedy)

[2] [https://www.witpress.com/Secure/elibrary/papers/FIVA08/FIVA0...](https://www.witpress.com/Secure/elibrary/papers/FIVA08/FIVA08036FU1.pdf)

</comment><comment><USER20> Here's a link to the actual keynote if you want to watch it:

[https://youtu.be/Yv4tI6939q0](https://youtu.be/Yv4tI6939q0)

<comment><USER21> Thanks for this link

</comment></comment><comment><USER22> OT, but not much, if anyone is interested in how/why buildings/structures stand up or collapse, there are a couple great books by Mario Salvadori:

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

Why Buildings Stand Up (1980) and Why Buildings Fall Down (1992)

that are elementary enough to be read by anyone, without being at all superficial.

</comment><comment><USER23> There's an interesting analysis of the Hartford collapse case here: [https://web.archive.org/web/20080108024915/http://www.eng.ua...](https://web.archive.org/web/20080108024915/http://www.eng.uab.edu/cee/faculty/ndelatte/case_studies_project/Hartford%20Civic%20Center/hartford.htm)

</comment><comment><USER24> Wow: I lived in CT in 1978 and it was a wicked snowstorm: 10 foot snow drifts shut the coast down. I remember reading about the collapse in the New Haven Register.

</comment><comment><USER25> Somewhat of a counterpoint - I didn't make it all the way through this book, but I think it has an interesting thesis:

The Death of Expertise: The Campaign against Established Knowledge and Why it Matters: [https://amzn.to/3aHdIBB](https://amzn.to/3aHdIBB)

</comment><comment><USER26> I am super surprised to see this on LWN. But it was a fascinating read.

</comment><comment><USER27> Just a note that priming has been a victim of the replication crisis.</comment>


Incredible shrinking NAND: I'm Meellllting: Flash array bubbles burst - <AUTHOR> http://www.theregister.co.uk/2012/06/12/nand_dying/ <comment><USER2> I'm fine with this, to be honest. Once we hit the limits of the technology the price will come down even further, and it will become standard.</comment>


How Global Wealth Distribution Has Shifted Since 1800 - <AUTHOR> http://thesoundingline.com/how-global-wealth-distribution-has-changed-since-1800/ <comment><USER2> Blogspam of

[https://www.gapminder.org/tools/#_state_time_value=1800;;&da...](https://www.gapminder.org/tools/#_state_time_value=1800;;&data_/_lastModified:1523631014976&lastModified:1523631014976;&chart- type=mountain)</comment>


How E-Books Make (A Lot Of) Cents - <AUTHOR> http://www.forbes.com/2009/03/21/ebook-iphone-oreilly-technology-breakthroughs-ebook.html?partner=contextstory

<comment><USER2> O'Reilly talks about success of "iPhone: The Missing Manual" as an iPhone app.

The app has outsold the book, and O'Reilly explains the business model validates as, " the data suggests that they have created growth without sacrificing print market share. "</comment>


Design patterns have (mostly) flopped  - <AUTHOR> http://www.supercoders.com.au/blog/designpatternshavemostlyflopped.shtml <comment><USER2> How about this:

Design patterns have flopped because many if not most of them have proven not to be the universal computer science gems they were touted as.

Rather, they've proven to be:

* Stock workarounds for the overly restrictive type system of a particular language X

* Patterns which in a more powerful language would be a language feature (or trivially abstracted into a small chunk of library code using the language's existing facilities for abstraction) -- but in language X, require so much boilerplate for each invocation, that the boilerplate merits a special name.

(Where for X, substitute mostly Java :)

<comment><USER3> Even in Java, most patterns can be implemented just fine in a small chunk of library code using the language's existing facilities for abstraction.

I think the relative popularity of design patterns in the Java community has less to do with the verbosity of the language than with historical accident (design patterns became popular at around the same time as Java).

</comment></comment><comment><USER4> I wasn't sure whether to upvote this article, until I got to this line:

> Design patterns are a universal language that few people speak, a sort of > Esperanto for programmers.

Exactly. And I fully expect many of the hackers here to chime in with 'oh, that article is so wrong'. But, the thing is, HN geeks, _you_ are that rare breed that knows and applies the patterns. I've met you, and I've worked with you. And for every one of you I've met in my career, I've met 200 who couldn't give a damn what a DTD is, let alone a pattern.

Design patterns are actually an excellent concept, but they won't really help programming for the masses. And, the more we depend on computing in our lives, the more we need programming as a technical discipline to be able to accomodate the masses. For every structural engineer out there in the real world there are probably a thousand architects. And for every architect, ten thousand carpenters. I know an expert carpenter and I'm pretty sure he couldn't calculate the tensile strength of a basswood 2x4, but he can sure build me a deck!

<comment><USER5> Counterpoints to what you are saying:

Actually the okay but not so good programmers are more likely to be hung up on design patterns. They have learned few of them, and try to apply wherever they can, even when they really shouldn't. Aslo people that tend to do over- engineer a lot tend to overuse design patterns. Also you will see them in interviewees asking a lot more about design patterns themselves than actually coding/problem solving ability. It is is just a higher end version of asking "programming trivia".

To the risk of being downvoted, I repeat again: overuse of design patterns is a hallmark of mediocre programmers, or programmer that are not very experienced yet (they may become really good one day, but not there yet).

<comment><USER6> Agree. Actually design patterns are really good to apply at refactoring time. You often cannot foresee what problems you will be facing and how your code will evolve in order to start trying to stuff in all the patterns you are familiar with. Write code -> see a problem -> identify a possible pattern -> refactor accordingly. This is also learning design patterns by doing.

<comment><USER7> I've found that Anti-Patterns (<http://en.wikipedia.org/wiki/Anti-pattern>) are the best approach for refactoring. They explicitly start with recognizing a bad pattern (frequently one which once made sense but no longer does) and then explicitly prescribe methods to refactor them into something better.

</comment></comment></comment></comment><comment><USER8> In my experience, few real-world problems fit neatly into one out of a handful predefined patterns. Having a few typical models to draw inspiration from when solving a problem is of course useful. Mindlessly applying a recipe without consideration of the unique aspects of an individual problem instance will inevitably lead to suboptimal or overly convoluted designs.

A skilled software engineer will recognise important aspects in a given situation and design a suitable solution based on similar situations (patters) without necessarily having a name for it.

Every attempt to formalise good engineering practices has met with a similar fate. Be it structured programming, design patters, agile development, or something else, they all fail when the chosen process is followed to the letter at any cost, no matter how absurd the consequences.

</comment><comment><USER9> Something that bugs me about these articles is how the data is gathered:

"In the recruiting work I have done I've asked thousands of programmers to explain the concept behind design patterns"

I'd have to find some data to back up what I suspect, which is that the bottom X% of programmers (or at least would-be programmers) cycle through all those job interviews where this lack of knowledge becomes apparent (unless you're recruiting for a really high-level position where the top programmers might be interested in applying, and even then many are already content where they are).

So, if you're any good, you're not as likely to be interviewed, and so the population is flawed.

That doesn't mean that design patterns have or have not flopped. At least, every one of my coworkers have been taught the patterns. Whether we apply them or not might merit a study, one with a methodology that doesn't mislead the observer and where a more valid conclusion might be reached (it could even be the same conclusion, that is, that they have flopped).

<comment><AUTHOR> Are you suggesting that great programmers tend not to have to go through the normal job seeking process, being interviewed etc, and therefore it tends to be the less competent programmers who end up having to go through interviews, and that these lower skilled programmers don't know design patterns?

<comment><USER10> The great programmers certainly go through _fewer_ interviews, since they tend to get hired quicker. And then they have a job, so they don't do interviews anymore. It's the incompetent programmers who are more likely to show up because they're more likely to (a) be unemployed and (b) go through more interviews before finding a job.

<comment><USER11> Really?? That's some strong opinion, which I disagree with.

<comment><USER12> This old Joel Spolsky article gives an argument to why that is:

[http://www.joelonsoftware.com/articles/FindingGreatDeveloper...](http://www.joelonsoftware.com/articles/FindingGreatDevelopers.html)

If you believe that good programmers are more likely to be offered a job than bad ones, it pretty much flows from that that bad programmers will be interviewing more. If that's so, then you are more likely to interview bad programmers. Statistically, on average, etc. Not in every case.

<comment><AUTHOR> Perhaps true that some good and great programmers get snapped up by people who know them and never need to look at a job board.

It's not true in general however that good and great programmers don't have to go through the normal channels to find jobs. I encounter many extremely talented programmers who weren't just snapped up by their network of colleagues.

<comment><USER10> Even assuming great programmers do look at job boards and go through normal channels, they're more likely to get hired and stay employed, which still makes the numbers game work out like I described.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> design patterns are recurring patterns in code. you may not know how often you're solving problems in the same way, but patterns recur, even if they're not one of the classic big-white-algorithms-book ones.

just because you dont have a class called Factory in your code, doesn't mean you're not using one.

and finally, if your programmer doesnt know what design patterns are, do yourself a favor and tell them to learn at LEAST what they are. they'll find a use for them, guaranteed.

<comment><USER14> should i read GoF or SICP? What is more importend?

Mmmhh I think im going to spend more time on SICP and PAIP then on the Gof Book and more programmers should do that.

<comment><USER7> Unless you intend to or need to program in languages with weak abstraction facilities (i.e. C++ and Java) there's little need to read the GoF book. If you know Lisp (i.e. have done SICP) then reading the GoF book will result in a "Where's the beef?" reaction, at least if you're anything like me.

</comment></comment></comment><comment><USER3> Design patterns are not, and never will be "important field of computer science".

They're a neat-seeming idea with very little practical value because the real world doesn't fit into a small set of neat patterns, no matter how cute you name them. Overall, they do more harm (usually of the "golden hammer" variety) than good.

</comment><comment><USER15> IMHO design patterns have been a great success because they have caused people to think about designs and suggested a vocabulary for discussing them.

Whether or not any specific world changing patterns have come out of the movement doesn't really matter to me. What matters is that the average blub programmer is just a little closer to understanding that classes are not just for modelling real world 'things'.

(I'm mostly an OOP programmer, assume something intelligent about functional programmers etc for me...)

</comment><comment><USER16> The design patterns I care about are things like "use a template system to generate HTML", and "create RESTful APIs that respond to GET requests with a JSON representation of resources", and "write unobtrusive JavaScript". The same general concept as the boring old Gang of Four patterns (describe a problem and the pattern used to solve it), but at a much higher level.

<comment><USER12> The GoF book is one pattern language among many. They were concerned with OO design that is used in a class of programs they had experience with -- basically GUI programs with runtime extension, and with a bias towards programs that create documents/digital media. There are many other pattern languages -- I could imagine one for web development that had your three examples and others.

</comment></comment><comment><USER17> Design patterns are universal. You can't avoid using them. The more important question is whether there are core design patterns which can be used regularly to improve the quality of software design, and whether or not we have discovered such a set of core patterns. That question is still, for now, undecided. Some of the canonical patterns (from the GoF book, for example) are useful, some have limited utility, overall there's a good body of evidence that that particular selection of patterns is far from universally applicable in software development.

</comment><comment><USER18> Not all patterns are equal. Of the GoF patterns, I'd say there are a few that are important to know: factory, observer, and visitor spring to mind. (Then there's the singleton pattern...)

<comment><USER19> Specifically, examine the singleton's usage pattern, and make sure it's not just a convenient excuse for a mud-ball of globals.

[http://sites.google.com/site/steveyegge2/singleton- considere...](http://sites.google.com/site/steveyegge2/singleton-considered- stupid)

<comment><USER9> On a followup interview to the GoF, they were in favor of dropping Singleton:

[http://www.informit.com/articles/printerfriendly.aspx?p=1404...](http://www.informit.com/articles/printerfriendly.aspx?p=1404056)

"When discussing which patterns to drop, we found that we still love them all. (Not really- I'm in favor of dropping Singleton. Its use is almost always a design smell.)"

<comment><USER18> Yep. The only justifiable use I've run across is internal bookkeeping in a class library across an API that doesn't provide space for context _and_ you need lazy initialization.

</comment></comment></comment></comment><comment><USER20> My experience with design patterns has been that their usage can prevent people from considering the deeper issue of what it means for a design to be good. I would far rather work with programmers that have a good grasp of the five SOLID principles, for instance.

This is not to say that specific patterns are not of merit in the right circumstances, of course. Just that the notion of design patterns as some kind of shrink-wrapped, off-the-shelf, one-size-fits-all solution is something I find mildly alarming.

</comment><comment><USER21> Hm. I've written 100's of thousands of lines of debugged deliverable code, and the number that matched a design pattern in a book was smallish.

Everything looks like a nail to a guy with a hammer.

</comment><comment><USER22> If you read the post and substitute "design pattern" for "algorithm", it sounds quite reasonable. Design patterns are not algorithms though, they're more like language-specific templates. I don't think they deserve the crowning glory of being in every CS degree.

</comment><comment><AUTHOR> If you were recruiting new people into your development team, would you care about the potential employee's level of knowledge of design patterns?

<comment><USER23> I would probably want them to at least know what they are, and why they are relevant to a task (or not relevant).

If they'd mostly programmed in modern dynamic languages (Perl/Python/Ruby) I wouldn't expect them to know most of the individual patterns, since they're not terribly relevant for those languages.

<comment><USER24> I don't do much Python and Ruby. But when I did do Perl there were tons of design patterns.

And Javascript, another modern dynamic language, also has a lot of design patterns.

I find it hard to believe that not all languages have their own design patterns. Just different kinds for solving the types of problems they tend to run into more often.

</comment></comment></comment><comment><USER25> The design patterns implemented by the authors of the API you are using are probably the most important (e.g. Key-Value-Observor in Cocoa).

</comment><comment> ryan-allen This article seems a bit spammy, and doesn't appear to be written by someone who is a programmer.</comment>