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

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.

-----


Thanks Andrew! Transparency and community involvement is our top priority here.

Also, we're doing a series of blog posts that will cover each part of the SDK stack. Lots of learnings to share from our kick ass SDK team.

Here's the first: http://blog.parse.com/learn/the-parse-sdk-whats-inside/

-----


YES! It's so important to be able to look under the hood with these things.

When I was working at MoPub, our open source SDK was one of our major selling points.

-----


Correction, MixPanel and Segment SDKs are open source. I don't know why I thought otherwise:

https://github.com/mixpanel

https://github.com/segmentio

-----


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.

-----


Is it illegal? I would expect it to maybe break the ToS or something contract related, not be criminal.

-----


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.

-----


The 'AppHub' stack looks good and can solve lots of problems.

However I think advertising it as a mechanism to get around the App Store review process is a quick way to get noticed by Apple, and not in a good way.

-----


I find how my two-year old classifies birds to be amusing:

1) He called all birds ducks for the longest time, presumably based on being exposed to a bath duck, and this weird Youtube video about ducks swimming in the water.

2) Then he called some of them bird, based on being exposed to a bath toy bird.

3) Then he split them up a bit more... parrot, chicken, rooster, etc. He started seeing them in books and real life.

4) At no point could he explain the difference. Still can't.

5) And he definitely thinks the only difference between a rooster and a chicken is colorful feathers.

6) And he's not quite sure about ducks and geese, but usually gets it right.

-----


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!"

-----


Yeah, jacques is definitely pulling my comment far out of context. I was commenting on his suggestion that everyone start serving their own JavaScript files, and writing custom code to check their sanctity.

I can't see the parallel here, or how that practice would have helped PagerDuty.

-----


In trying to hire, where are you posting job ads? Or are you using recruiters? Both?

-----


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.

(For any developers looking to work at a cool startup, shameless plug: http://readme.io/careers/)

-----


No good developer applies for jobs

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.

-----


Joel is more eloquent at expressing the problems with hiring than I:

http://www.joelonsoftware.com/items/2005/01/27.html

http://www.joelonsoftware.com/articles/FindingGreatDeveloper...

-----


Why would you even post job listings and ask people to apply, if you think no good developers apply for jobs?

-----


I guess I meant that no good developer is out looking for a job on something like Angellist or Hired.com. And plus, it never hurts to be a bit optimistic, I suppose.

-----


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.

-----


I think it depends on your market. Where I am, there are a lot of people just using their personal car. I heard the minimum is a 2000 year car in good condition, which is about 15 years old now.

-----


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.

-----


Yes, the average person has a vehicle.

-----


That's a simplistic view.

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.

-----


1) I wish you'd dispute the meat of what I said:

* 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.

I imagine the cultishness is recognized and unwanted... hence pg not being on the leaderboard: https://news.ycombinator.com/leaders (and totally withdrawing from the site overall)

-----


> This site serves the startup community,

No the site serves YC that it happens to have some overlap with serving the general startup scene and hacker crowd is a good thing but it's not the primary thing.

> the community will go elsewhere if the values of the site don't lead to good content/community.

Only if a threshold is reached and there is a consensus that it's time to move on, there appears to be no sign of that, realistic people realise that HN while a valuable resource belongs to YC.

-----


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.

"If you have to use externally hosted resources such as javascript libraries then at a minimum you should verify regularly that the code has not changed "

No, you shouldn't. You should focus on stuff that matters to users, not existential internet security holes. Let someone else fix this problem for you, when it stops being existential.

By far the safest approach for website owners that care about their users and their users privacy is to simply not include anything at all from other people’s servers.

FTFY "A safe, but impractical and productivity-destroying aproach..."

-----


> 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.

And every time some user gets their day ruined by some formerly javascript widget hosting domain that got transfered to a new and malicious owner there is a bit more evidence to support that that approach is the right one.

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.

-----


Explain to me like I'm five what features a website that hosts it's own javascript can't have versus one that loads those same javascripts from remote source?

-----


It can't have the features that would have been built, in the time spent learning about and implementing security.

I regard nearly all security for startup-class, low-user, and low-value companies to be premature optimization, which is deadly to a new project's potential.

-----


> 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.

-----


I see. Copying the javascript you use into somewhere on your own site does take too much time.

-----


Then let them die.

-----


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.

-----


Your view on this screams "Tragedy of the Commons."

-----


I hope you don't develop any websites I use.

-----


Users assume the sites are safe and not malicious or open to attack.

There are an enormous number of implicit contracts between us as developers and our users that are not written down but are still "stuff that matters to users".

Ask a bank auditor if they think security holes does not count as "stuff that matters". Then try selling your services to said banks. It matters

-----


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.

And the consequences can be just about anything.

-----


One of the first books that I read talked about the story of the backup tapes on the car seat that were erased when someone in Sweden (?) with heated seats drove home. (urban legend iirc).

-----


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.

-----


Open source Hearthstone-like game, except it's real-time (no turns), and it's space-themed: https://github.com/lacker/cardkit

It's an effort to learn more about react.js, Webpack, babel, and ES6. Contributors welcome. It should be easy to build and run. We have a Slack channel for people who have contributed.

You can play the basic game (if you have an opponent) at http://spacetime.tv (very much a work in progress)

-----


Not working for me.

- Uncaught InvalidStateError: Failed to execute 'send' on 'WebSocket': Still in CONNECTING state.

- WebSocket connection to 'ws://spacetime.tv:9090/' failed: Error in connection establishment: net::ERR_CONNECTION_TIMED_OUT

-----


Hmmm... Spacetime.tv works for me when I connect two browser windows to make a game.

a) What browser/OS are you running?

b) Maybe your firewall is blocking sockets?

-----


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.

Any feedback is appreciated.

-----


No, can't say that I have. We sometimes collaborate in realtime on a Google doc, Trello card, or Screenshare on Hangout.

Maybe we have a more show-and-tell-and-iterate approach.

-----


Dang. Oh well.

-----


I always use https://awwapp.com/ for that purpose.

-----


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

-----


Yeah I thought about equipping everyone with a wacom and then finding a good way to share that experience. Or maybe find an iPad app, since the iPad would be a lot more useful than the wacom. :)

-----


a) Yep, I agree, all remote or all local. That's my experience as well. Mixing the two doesn't work very well at all.

c/d) Yes, you definitely want mature people who understand what remote is all about. If you don't have that, it won't work.

e) Zoom is pretty good. No email? Huh! That's a new wrinkle I haven't tried before.

-----


There are very few things we want to email about that don't better fit in a Slack channel, or as a Trello card.

Our Slack channels are: Dev, Comm, GIS, Recruiting, and Random

We basically only email if an outside party sends us some big email to discuss.

-----


Email tends to work better for things you want to archive. Especially if you're not actually paying for Slack.

-----


Second time I see Zoom mentioned here, but never heard about it before. What's the benefits over Google Hangouts / Skype?

-----


> frequent one-on-ones

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.

-----

More

Applications are open for YC Winter 2016

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

Search: