The issue there is that the value of those tags decreases if the majority just accept those tags suggested (which from what I've seen, most users do). There's no penalty to giving a tag, so if someone says "What to help one of your mates get a job by spending <1 second hitting a button" there's no reason not to (beyond your personal principles at least).
To fix the system you either need to limit the number of endorsements you can give (e.g. you're allowed to give 3 endorsements (to anyone) for each contact you have), or have some way to force a comparison (e.g. is A or B a more competent Java developer in the context of Gaming?).
(of course, this assumes that you wish endorsements to have meaning; if you're just using it to increase user engagement with your site the current method works fine - until people get fed up with putting in redundant effort).
How to fix endorsements - rather than asking if someone has a skill, take two people in your circle claiming the same skill and ask who's more competent at that. Repeat this for all people in your circle with that skill and you can bubble sort people into who's best in your eyes. Next take those people's standing within their respective circles, perhaps weighted by some measure (e.g. people working in the same field's opinion counts more) and you start to get a good idea of how people compare to one another for the skills you're interested in. Even if those people don't have anyone in common you can use the 6 degrees of separation to use their connections' connections to approximate their standing compared to one another.
Has anyone considered a SCRUM funding model? i.e. Similar to how Patreon's used to fund ongoing deliverables from YouTube artists (among others) the team could have patrons sign up to pay a smaller amount on a fortnightly basis, with the development team announcing their goal for that sprint, then taking funding on delivery. This gives patrons the option to back out further down the project if things go off course/change, thus reducing risk in committing to a failing project, whilst allowing other patrons to sign up down the line as the project starts to look increasingly feasible.
Optionally small awards could be given per pledge, whilst larger rewards (e.g. your own phone) given to those who've given a certain amount by the end of the project / the pledged amounts could be discounted from the resulting phone's price.
One minor "bug" / missing feature; I have two monitors at different resolution; when moving the browser (maximised) from my laptop monitor (1440 x 900) to second display (1280 x 1024) the staves are put on a different line to the instrument names. If I refresh the browser on my second monitor then move to my laptop screen all works fine though.
The same issue exists if I resize my browser; i.e. currently window.onresize events aren't handled.
Great work though - and nice choice of pieces too.
I like the way this has been presented, but have to admit that I disagree with the point - if someone's willing to give me something for free (monetary) in exchange for reading info I pass through their services I'm fine with that - I just won't use their service to send anything I don't want them to read.
There are good arguments for privacy, and for people/organisations being open about how they use any personal data they collect, but in this scenario you've willingly and knowingly signed up to a contract; and in doing so invalidated your right to be upset by the required "payment method" of information.
Build your solution suitably decoupled, such that if you lose access to the API you can easily switch to another provided. Ideally build solutions across two competitors services such that if you get any surprises it's clear that your solution works / users are able to migrate to the alternate provider.
For authentication I'd argue in some ways it's better to provide the option of third-party. This means users don't have to submit credentials to you. Given most people (against advice to the contrary) use the same username and password for most sites signing up to an unknown company's service feels riskier as they're then giving that company their credentials, which someone may then try on other sites - having a token which allows them to sign in with their Google/FB/Twitter/etc account saves this worry / only requires the user to hit an "authorise" button.
Agreed. My argument was that the government asking the company to do something immoral would be more of a concern to me than the company doing it, since the government is supposed to hold a position of trust with its society whilst the company is generally assumed to represent its owners and/or investors interests.
When a company does what's asked of it by a government and people are upset with the company something's seriously wrong. A company's main priority is typically to make money within the bounds of the law. A government's should be to improve the quality of life and uphold the moral values of its citizens.
I have a feeling had Apple been first on board rather than last the journalist would argue that Microsoft were evil for not complying with a government request and that Apple clearly had the vision to help the nation's security, but maybe that's just me?
My guess is enterprises were scared of going the SaaS route; partly as this model is still relatively new, but mainly because companies like to keep their data in house (or at least need the option to easily get hold of a regular backup / with some way to quickly restore it should the vendor go under).
Point number 3 are words I'd love to hear from more founders. Admittedly many need to take a salary too (since their site is what they do, but to be a user of your own product and have that passion for it is a great way to ensure you produce an awesome product.
1. Provide a demo option if login's required
To avoid asking for people to use features like facebook connect upfront allow them to use a demo version of the app. This gives them a chance to have a play with the app before committing to it / exposing their identity. That's particularly useful for HN audience who will pop to your site in order to give you feedback, but also useful to potential users who want to understand more about what your site is than they read on the blurb on the front page.
2. Read all feedback and decide what's relevant
Ignoring feedback on particular subject areas just creates a blind spot. Read all feedback and use your own judgement to determine if the person has a point or not. They may be wrong, you may be wrong - but at least if you read the feedback you'll have considered things you may not have previously.
3. Focus on the constructive feedback.
Pay more attention to comments which give a problem coupled with a solution - those pointing out issues with no suggestions are more likely to be ranting (~generalisation) whilst those singing your praises aren't giving you anything to improve what you've put out there (though a few such comments are always nice to soothe the ego after reading some of the harsher posts).
4. Look for common themes in advice.
If lots of people are giving the same advice (e.g. I wouldn't pay $100 for this up front, but I would pay $10 a month) consider what they're suggesting - whereas if one person's ranting that something's too expensive you can probably ignore it. As with all advice it's about using your judgement rather than ignoring the advice outright because it's about xyz.
5. Avoid asking for a credit card upfront
Same as #1 - provide a demo option which avoids the need for a credit card / perhaps give a first month free option to allow use of the product without card details. If someone from HN goes to check out your app and give you feedback, you shouldn't charge them for their advice. If a potential user can't play with the app before paying for it (or trusting you with their details having seen no more than the front page) they'll also be less likely to join.
The definition of a full stack developer is someone who can develop for all of the technologies involved in the stack. What those are depends on the stack (e.g. Postgres SQL + Ruby on Rails + HTML5 + CSS + JS vs. SQL Server + C# + AppFabric + WinForms vs. every other combination of technologies people may be developing on).
Understanding of hardware / environment is a useful skill for any developer - not just a full stack developer - the only difference is the full stack developer needs to know about the intricacies of all areas rather than just the parts which affect their part of the stack (since they're dealing with all parts of the stack).
Understanding of the business is again outside of the definition of a full stack developer, but is a useful skill for any developer to have - if you can understand the problem you aren't so reliant on the spec/analyst to dictate requirements to you meaning you can make assumptions about how your code may change in the future and consider edge cases which are important at a technical level but analysts wouldn't have spotted from a functional level.
With both of the above points these are definitions of good developers - but don't sit in the core definition of full stack developer - the same as a good musician should be good at languages since they'll likely tour; but not speaking French won't affect their piano performance.
Same philosophy here. I do use privacy settings in FB and G+ just to avoid spamming folk - I'll post things to public which I think anyone who follows/finds me may like, then use privacy for "audience targeting" as sharepoint folk would call it.
This is an amazing project - like Kickstarter, but rather than placing a large bid for a one off project, this allows you to give small amounts to regular deliveries. This encourages artists to keep creating content, without having to run another campaign for each mini project.
The site's not restricted to which types of projects it funds. It could be musicians, artists, YouTubers, developers (e.g. if you want to release new levels for a game, or keep creating mini flash/mobile games), or anyone else.
*This site has been posted before (https://news.ycombinator.com/item?id=5671267), but didn't get spotted as it was posted during a busy period, so never got the views to make it out of the new section.
ps. All are from Japan, US, Italy or UK. I suspect that may be down to record keeping as much as lifestyle.
For example, a friend's wife is from Turkey and doesn't know how old she is as her date of birth was never recorded; one year her parents just made a guess saying "well, you were born in summer and you look like an 8 year old, so we'll stick you down as 21st June 1965".