Freaking awesome! So much to learn from the code from these guys... plus easier to use, more trustworthy... and you don't have to wait for the vendor to fix critical bugs when needed.
I'd really like to see all infrastructure SDKs open sourced (obviously a tough sell, but maybe Parse paves the way). In building our core stack, we don't tolerate closed source. But we end up allowing it for things like Crashlytics, MixPanel, Segment, etc - and it's not a free lunch.
Yep, "feature flipping" can lead to app rejections and getting booted from the store.
* If the AppHub founders think this is a real danger, then you'd expect bold and strenuous documentation.
* But, I wonder if the AppHub authors believe that people should ignore this rule, because practically speaking it's hard to get caught. They wouldn't say so, of course, because encouraging people to break Apple ToS is illegal.
It feels like it might be some sort of crime specifically to misrepresent your product as being capable of X and sell it to people who you know will try to use it for X, when X is disallowed by the ToS of the platform. Con-artistry of a sort.
You could see that as "false advertising", but considering they link to the Apple TOS they're not really hiding everything.
And actually, merely adding features doesn't seem to be forbidden as long as the features you add are not "inconsistent with the intended and advertised purpose of the Application as submitted to the App Store"
So let's say you release a file manager and later, surprise! It's also a SNES emulator! Well, then yes, I can see that against the TOS. But if you're just making improvements to your app, I don't see a problem.
I think illegal is the correct word there. I won't comment on the statutes (IANAL).
It was just a hypothetical though. AppHub has plenty of legit use cases under Apple rules, and it's probably not all that dangerous even if you "mis-use" it slightly. AppHub would have to explicitly encourage people to break the rule to run afoul, or Apple would have to organically notice a bunch of apps doing a bunch of outlandish feature flipping.
With the way the CFAA is enforced, you look at a computer in a way someone with money doesn't want you to and it's federal prison worthy. I'm sure an over eager DA could and would try and make the case.
I guess he still needs to develop the advanced bullshitting (sorry, I meant "rationalisation") skills required to say, "Well, I think it's a duck, because it looks like my internal picture of what ducks are supposed to look like, dear sir!"
I can't see the parallel here, or how that practice would have helped PagerDuty.
My comment was more glib than a real complaint about how hiring is going for us. No good developer spends time on Angellist; it has to be proactive. That being said, we do get dozens of inbound applications every week from dev bootcampers who find us through Hacker News job postings/Angellist/etc.
Ads can catch good people in transition, or looking for a change.
Anecdotally, I've hired truly great people, and interviewed ex-Googlers and other good pedigrees, from Stackoverflow Careers and HN posts.
1) I once hired a pre-Googler on StackOverflow even - a guy who was on his way to Google in the fall, but liked my project, and wanted a summer gig. He intended to spend a few months vacationing, but got bored.
2) Another guy I hired via HN originally just left for Facebook, this month :(
3) And our current, long term, best developer, I found on Careers StackOverflow. I credit him with much of the success of our company. He's a special combination of outdoorsy and amazing coder, but no college or professional pedigree. He was hurling dynamite at avalanche banks when I found him, coding amazing apps with little revenue potential.
Then are you just round-filing CVs that you get via that path? Because if you really think that you'll get no good candidates that way, all you're doing is introducing needless noise into your search process by cluttering it up with unwanted candidates.
Either you're not being honest about your opinion of those sites and others like them, or you are behaving irrationally.
"The average person has a vehicle that might possibly be shared via Uber."
Wait, is that true? My experience with Uber drivers is they all bought a new car to be Uber drivers, sometimes with a loan Uber helps them get.
Uber being some kind of "sharing" economy company seems a little dubious. They are really quite different than AirBnB, which really is based on a surplus of housing.
Uber is mostly just a taxi company, and their fleet is all pristine, new cards, which they make drivers get and maintain. And the drivers are only "not employees" according to a very fine line.
It's more like the "1099" economy than the "sharing" economy. Uber isn't leveraging a car surplus - they are capitalizing on a worker surplus. There are no beat up old jalopeys getting "shared" via Uber. There is no natural, organic market, among people with/without cars.
Yes, I thought about addressing this in the comment. Most Uber drivers are much more like 1099 contractors, but I think for this purpose a general notion of what a "sharing economy" entails is sufficient for the purposes of comparison with this idea. Either way it just doesn't hold up.
This site serves the startup community, and it's warped by the wants/needs of YC because of its genesis.
Bringing in moderators like dang has helped a lot - the site definitely got too cultish around pg and YC, and it seems like things have improved since then, both content and attitudes of people on the site. There seems to be more of a chinese wall between decision making for YC and HN now.
I would hope/think over time that the remaining unfairness will drift away, like the fact that YC founders see each other highlighted, so they can form a casual voting rings around YC stories (and the job ads I agree are unfair and bad for the community too). It's not even healthy for HN/YC long term - the community will go elsewhere if the values of the site don't lead to good content/community.
Following the money is rarely simple and is an heuristic of high utility. Alas, it often leads to a world view that is less comforting than I would wish. The success of HN is, in my opinion, due to the large degree of alignment between YC's motivation for HN and the benefits of HN for individual users. The alignment is possible because YC's business thrives on monetizing extreme outliers and ignoring the fat middle. This enables it to thrive on HN's exhaust fumes.
If for no other reason, job postings for YC companies is useful for reminding the HN community that HN is a business asset not Usenet. The reason it is useful is to rationalize a set of standards somewhat similar to a workplace.
This comment is unfair to PG. There's no way for you to know this, but behind the scenes PG has always been protective of Hacker News and has been aware that HN exists outside of YC and has utility for the community at large.
YC founders are actually subject to voting rings as well, and often get dinged.
I get that there is a knee-jerk anti-authoritarian kind of sentiment here, but in this case, the tone and attitude is undeserved.
* That YC founders can see each other differently on the site (colored names).
* This naturally leads to more upvotes for YC stories.
* These upvotes would be unlikely to trigger voting rings.
* This provides a non-transparent (unfair?) advantage for YC startups, and a false signal about the interest in these startups overall for people unware.
2) The job listings thing I have less to harp on, but I still find it a little weird that there is a hugely popular job board reserved for a few hundred companies.
3) The comment wasn't intended as an attack on pg, and I understand the YC is from the top down well-meaning and full of good people. But the site is better, more transparent, and more fair under the new management, at least it seems that way to me.
> This article should be read as ranty research, not practical advice. It'd be fine to fix these issues, but not at the website developer level.
That's fine, it's only your users after all.
> No, you shouldn't. You should focus on stuff that matters to users, not existential internet security holes.
If you can fix a hole until that hole is plugged in a more permanent fashion then I think that you should.
> FTFY "A safe, but impractical and productivity-destroying aproach..."
Entirely practical and with minimal impact on your productivity. If you can find the time and expend the effort to build a product to begin with then you can certainly find the time and expend the effort to make a conscious decision about things like this.
It matters enough to me that it affects my choices with respect to which parties I deal with on the internet and I sure hope I'm not the only person that thinks like that.
From the end users point of view as long as it works the two solutions are identical and if you're serving up megabytes of content anyway what's the big deal about serving up some scripts directly as well?
No, the solutions are far from identical to the user.
In Jacques' universe, websites are more buttoned up, and less feature-ful. Every non-banking, non-critical website is taking worthless security steps in secur-e-verse, and hurting their product.
In the real universe, developers of new fluff websites focus on features and user experience, grow successful, and attract many users. Developers who takes Jacques approach build websites that fail and never get used by anyone.
And also no, no, no.... no one is like you. No one cares if developers do what you propose, no one avoids websites that don't.
> I regard nearly all security for startup-class, user-less, and low-value companies to be premature optimization.
I can't see anybody working on user-less websites anyway but I sincerely hope that you'll make it plain which start-ups you work for so I can avoid them. Security and abuse potential are very important for start-ups because you have only one reputation and if you lose that you're pretty much done for.
I can point you to several pretty harsh reminders of how start-ups that don't take end-user security serious can end up.
One thing that I have seen over many many years in business is the need to decide where and when to cut corners and take chances. I have definitely seen that after the fact you could feel "geez I should have done that how stupid" but before something actually happens things aren't so clear that resources and time and money should be spent preventing something from happening.
I have noted that if I did everything perfectly (and I am not talking specifically about money) I would never have made any money at all. (Exaggeration for effect.) There are always things that you can think of that seem like a good idea and you can't do all of them. I take the time and put in the money and effort to rotate and store offsite backups. However in all of these years that has never been needed. But God knows we all are aware of a ton of small businesses living on the edge who probably don't have good onsite backups, let alone offsite and they do have information that they need.
Agree the advice is well intentioned and is correct (in theory according to what I read) but not entirely practical. For example:
"then at a minimum you should verify regularly that the code has not changed (you have to hope that you are looking at the same code that your users see)"
Who exactly is the "you" in the above statement and who pays the "you" money to fix this and keep on top of it on an ongoing basis? And for how long?
In the physical world the different between ideal and practical can be described by my experience with production machinery. The machinery came with guards to protect the operators from getting their hands caught or cut off. The guards also came with switches to prevent the machines from running when the covers were taken off. But what would happen is the operators would want to oil or tweak the machines so they would take the covers off and disable the sensors so that the machine would run bare. Of course you would tell them not to do this, but they would still forget to put the covers back on or be lazy quite often and there was little you could do about it. You had production to get done under deadline and weren't likely to fire someone even though you knew there was a small safety risk in doing this type of thing (older machines of course came with no safety guards at all, operators just had to be careful at their own peril. (And good operators were impossible to find anyway so once you had someone they became a primadonna ..
Regularly pulling a hash for the libraries you include and alerting you when a hash changes unexpectedly is no work at all.
And if you need to be paid money to fix it then you have a problem anyway so one would assume that you'd be paid just as much to fix it when you're being alerted to it by a cron job as you would be paid to when you're alerted by a horde of users.
As for machines without guards: I've worked (extensively) in the metal working industry and the number of people missing digits and limbs has decreased steadily ever since tampering with guards, safety-interlocks and lock-outs became a firing offense so I don't think that's a very good example.
Machines: Yes this was the 80's (sorry I didn't point that out my mistake) and things have changed. However to that point if you have your golden machine operator turning out good work (and he is only 1 of 2 on a particular line) and it's not easy to hire a replacement, let alone a good replacement, you tend to get a bit lax.
Security: I am primarily a business guy (who does some light programming and knows Unix since the 80's) so I hire others to do work for me. I am just thinking that for the people that I have hired in the past how would anyone know if any of this is happening (other than code audits) and what is the mechanism to make sure the right thing happens even if you know what the right thing is? It's kind of a version of the advice "make backups but make sure that you test your backups as well".
The motto is 'trust but verify', and indeed that goes for your backups as well. And incidentally that's one of the most failed items during the dd's I've done and after verification several companies turned out to have lived without backups at all.
It usually takes two things to go wrong for a disaster to happen: some $0.05 part that fails and a procedural error.
Iirc Saab pioneered heated seats because one of their engineers had colon cancer and Saabs are pretty common in Sweden, but I'd still wager that's an urban legend because the heating is done with DC current and to reliably alter the contents of a tape you'd need a lot more of magnetic field to overcome the resistance of the magnetic particles to change direction (remanence) and you'd want that field to alternate.
>> Who exactly is the "you" in the above statement and who pays the "you" money to fix this and keep on top of it on an ongoing basis? And for how long?
This is not a negative! This is an upwelling opportunity for a retainer. I know someone whose business is warranting other agencies sites - he patches holes in a site they built but don't see the percentage in maintaining - he is doing well enough to hire in new folks.
I was doing hashes of jquery certainly five years ago and I suspect earlier - it's one of those rings that seems obvious in the buildscript.
We've done both (office in Berkeley, but now two founders in Berkeley, and the other 7 or so around the US).
A couple of points:
a) It should be all remote, or all local. You ruin the fun for people if a chunk of the team if talking, and chat is dead.
b) My co-founder/wife and I purposefully avoid shop talk, and keep it all in chat.
c) Remote is a good life style for some people. We look for people who will be happy at home, people with lives and families, who don't need to meet friends to go out with and lovers at work. This fits our culture - we attract outdoors types, who like time to themselves.
d) Some people are self-driven and make good remote workers. Some people need to be in an office and get constant nudging from physical social pressure (and their boss).
e) Tools: weekly Google Hangout, frequent one-on-ones, Slack, Trello, Github - almost zero email.
Hey, question for you. Have you found a good "remote whiteboard" solution? Our company is all remote, and this is the one area where things could be better. Sometimes we really want to just get in a room and whiteboard something, but we can't.
Please check out Deekit app @ https://www.deekit.com and see how our tool can help with your teams whiteboarding issue. It is free (for now), browser based (chrome or firefox preferred), with IPad app coming soon.
just brainstorming (haven't tried it) but as a low tech solution have you tried screensharing somebody's desktop running something like Krita? If most people have a wacom tablet they ought to be able to just take control of the session and draw on the "whiteboard" with also the advantage of Krita doing smoothing and making handwriting look nicer in general
Doesn't that just waste people's time? The weekly google hangout as opposed to a daily one is a good decision. Less disruption to those actually doing the work.
> a) It should be all remote, or all local. You ruin the fun for people if a chunk of the team if talking, and chat is dead.
I've worked in both situations. I'm remote now on a 100% remote team, but I've also worked in the main office and communicated with two remote co-workers. With Google Hangout and Zoom, I've noticed no difference between these two setups. People who work better by talking everything through in person will just use google hangouts to have conversations with the people they need and leave the rest out. You still wind up with some people being left out of the loop and chat is still 90% dead, except for the occasional entertaining gif and water cooler talk.