developer1

Two people making $25k/yr should be individually paying the taxes on their own $25k. There should be no ability to transfer tax burden between partners. An adult makes $25k, that adult pays the taxes due on $25k. It's not a difficult concept, and puts everyone in the same position, partner or not.

The glaringly obvious explanation is that people are buying the quantity they wish to eat. Why is it so unbelievable that people will buy 10 nuggets instead of 20 for the same price? I'm not going to take 10 extra nuggets and either throw them out or put myself into a food coma.

If we were discussing 1 vs. 2 cans of soup from the local grocery for the same price, of course everyone would buy 2 - you can save the additional can for another day. Here, we're talking about fast food that has to be eaten within a couple of hours. There is no "deal" to be had by buying a larger quantity if you're not willing to eat it.

The only sad thing about this article is the apparent inability to understand why someone won't stuff their face with more food than they can eat without making themselves sick and likely obese.

True. To be more specific: while UAC is great for requiring admin privileges, it would be nice if UAC prompts would enumerate the permissions being asked for. The prompt should be asking you if you wish to allow the program to disable Windows Update as opposed to "admin privileges to do anything whatsoever with your operating system".

That said, it's a difficult system to implement properly. Android went that route, and it almost works - almost. Android's available permissions are too plentiful, and yet certain permissions are too broad in scope. I wouldn't want a desktop application to have to ask for separate privileges for every little piece of functionality, but for certain critical actions it would be nice to have some clue as to what is going on.

Perhaps in another 20 years someone will finally invent a privilege escalation system that somehow manages to be both very specific and yet not time consuming for the customer to manage. What a dream. :)

I'm so tired of the financial benefits that a) married couples, and b) parents, receive. Being married or having children should provide exactly zero financial benefit from governments beyond what bachelors/bachelorettes receive. It makes absolutely no sense that simply hitching yourself to another person or reproducing magically means you get government handouts. Neither of these situations provide substantial benefit to society deserving of special treatment. The discrimination against those of us who remain single is just mind-blowing.

Every adult should have the same government-mandated financial burden and reimbursement cheques in the mail. Why shacking up or pumping out kids gives the adults involved an advantage in their financial livelihoods is ridiculous. :(

For the typical larger project, you'd wind up with hundreds of indexes each used by a single application query. The optimal index arrangement for a database often does not result in all columns being indexed on a query. It's normal and desirable (for index size and performance) to have fewer indexes that may only partially cover your queries. For example, a query with a WHERE of "a AND b AND c" is more often than not better handled with an index on (a) or (a, b) rather than (a, b, c). Especially if you have a second query with "a AND b AND d", you're most likely going to wind up with a single index for (a, b) rather than one for (a, b, c) and another for (a, b, d).

What could be useful would be a generated report for all your queries with possible suggestions, grouping together queries with the same partial prefix columns, and the cardinality that each index would result in. Then one could manually review to look for the most significant improvements possible. I think a fully automated attempt (even built-in heuristics that modified indexes over time) would sometimes result in a bad decision being made that could theoretically crash your application. Perhaps with a few years of perfecting a solution this could become the norm. :)

Of course the video doesn't show anything interesting, the mosquito's leg is hardly even grazed. I was definitely hoping for the version where a drop smacked the insect dead on target. Fairly strange for a lab result - if that's the only video that was captured, it really doesn't seem to divulge much at all. Where's the cool video? :D

Or you know, place the ability to disable Windows Update behind policy restrictions and UAC rather than being openly editable in the registry? With policy restrictions, corporate installations could deny all attempts to disable the service. In non-corporate environments, this should at least require a UAC prompt. While too many users would likely click through without understanding, at least knowledgeable users would understand and be able to deny the change.

Windows Update is a serious security requirement for any Windows install. Disabling it should clearly require explicit consent from the user.

> it makes sense to take somebody at under their market rate, and 3 months later have a chat with management and bump up

Another strategy too commonly used by poorly run companies. If you feel someone will be worth $X more in only 3 months, they are worth paying that from the start. Kick the employee to the curb before their probation ends if they don't meet your expectations for the full salary. These games some companies will play ("we'll hire you at $x and then in 3 months we promise you'll get another $x") is despicable manipulation of employees' trust.

I worked for one company that did this to any new hire that was a pushover (they tried with me, I only accepted after constant back and forth for "HR approval" of my expected salary which was average market rate at the time). The gimmick is that nobody automatically got the promised raise at 3 months, and nearly everyone who went to fight for it never received it. An employee had to have already embedded themselves deeply enough into a product and be considered a "hero" in order to receive anything. The result was that the great developers would leave after being stabbed in the back, leaving the least talented people in play.

Suffice it to say, I don't even negotiate for salary or vacation time anymore. I request $x and X vacation days, and if the first offer comes back with anything less, I give them one chance to fix it. If the second offer is still shortchanged, I drop them. Unless you are desperate to find a position for financial reasons or you need your first job in the industry, these games being played during the hiring process are a strong indication as to the quality of the employer in general.

What the hell. A developer who writes x << 3 instead of x * 8 when writing code that is logically doing multiplication is not a good developer. Written code is designed for human readability; the human should not be having to convert that mentally to its math equivalent to understand what operations are taking place. In nearly every possible case, this is at best a micro-optimization. At worst, a symptom of someone who writes unnecessarily obfuscated code to show off their knowledge in a manner that only hurts the maintainability of code by a team.

If I found bit shifting in an interview code sample as a replacement for basic multiplication, I would ask the developer why they chose to do it that way. They'll either a) calmly explain that their computer science classes taught it that way or it's a habit they've adopted after writing code for embedded systems or similar where the optimization actually made a difference, or b) their ego will make an appearance with a "because I'm so senior" attitude. The latter is not a good sign.

> the main restriction ended up being the maximum salary we were allowed to offer (which had us have to give up on half a dozen candidates)

Ugh. I've been in a similar position, assisting with pouring over candidates. The worst part about salary being the limiting factor is you've quite literally wasted your time weeding through the poor candidates to find the honest-to-goodness best to hire - only to not be allowed to have the cream of the crop. It's ridiculous how much time some companies are willing to invest in finding the best talent, only to turn them down because of an extra $10-30k/year. If you're not willing to hire the talent, don't spend the time searching for them. Just post your job ads with your salary expectations, and accept the first people through the door if that's how you're going to operate.

Strangely with Canada, I think it depends on where within the country you immigrate to. As a native Canadian from the prairies who moved to Montreal 10 years ago, I have met and worked with so many immigrants here that I now believe I know more of them in Montreal than I do native Canadians. It makes for an extremely interesting cultural mix.

Apparently Quebec makes it much easier for citizens from a select list of countries to obtain permanent residency, as opposed to what you'll find elsewhere in the country. It still takes a long time dealing with loads of bureaucracy (especially the requirement for basic French language skills which can be handled via courses while here), but I haven't yet met anyone who has had to leave before they manage to obtain their permanent residency.

Random aside: Moldova has proven to be the source of my favourite people. There are so many Moldovans here due to a simplified immigration process for their country. There's just something so refreshing about how they carry themselves: friendly, humble, utterly proud and self-confident, and without ego. It's nice to meet people who are pleasant without plastering a fake-ass smile on their face all day long. When you see them smile or hear a laugh, you know it's genuine!

tldr; I believe Quebec is conditionally easier (based on country of origin) to immigrate to than other Canadian provinces. And, um, Moldovans are genuine people - more of you need to move here so I can eventually find a lifelong mate. :p

The Chrome Dev Tools geolocation emulation has become a hit. North Korea, Antarctica, and the RMS Titanic are all online.

I just looked through Google Map's API licensing options. Obviously you may quickly max out your limit. It doesn't look like there's really an extended paid model to increase the limit by much? 100k requests is the only additional limit I see.

Does Google not offer much higher limits if you're willing to pay? I'd be curious to try a similar app, but it seems that popularity might kill one pretty quickly with such low API limits.

Two features to replace dragging:

1. Fade timeout on messages (10 to 20 seconds).

2. Clicking on a chat bubble needs to bring it to the front (change the z-index). Sometimes just want to read a specific message hidden behind another, and having to click to close gets tired fast. Extra bonus if future messages from the same person you've clicked on once always pop up on top of others in the area (or provide a little "pin" option in each chat bubble, but that will probably clutter too much).

And as a separate suggestion already mentioned by others:

3. The ability to toggle the enableHighAccuracy boolean. Exact street address is a little too creepy.

Articles like this are harmful. There are many of us successfully using gitflow without _any_ of the issues raised in the article.

And yet people who want to argue against the use of it simply because they don't want to learn something new now have a useful link to throw around as "proof" that a very successful strategy is "harmful". I guarantee in the next year I will have to go point by point and refute this damn article to some stubborn team lead or another senior dev.

Nobody should ever write an article outright bashing a strategy that they either don't fully understand or personally have not managed to integrate successfully in their own day-to-day. Bare minimum, if you're going to publish an article critical of a tool, don't name it so aggressively as to sound like it's fact rather than a single personal point of view.

I believe you meant to say "it proves your business isn't as squeaky clean as you make out". With a response like that, clearly their business was operating in some kind of grey area. It's unfortunate that when this happens, the company (ex: Stripe) can't come back and disclose specific details about the scumbag making a stink on HackerNews over something that the company was perfectly in the right to shut down.

Unfortunately, a lot of businesses want to accept credit cards online with little to no effort in managing the risk. 1-2% doesn't sound like enough wiggle room, but if a company isn't using misleading marketing, is not defrauding users, has a product actually worth what they are charging, and offers instant support for refunds - then staying under 2% is not difficult. Too many businesses want the risk to be handled by external forces. If you want to accept money online, make sure your business is prepared to manage the risks. You can't just drop in the payment processing and wait for the money to roll in.

Does the NSA allow its employees to look for help from the general public like this? Seems odd for such a secretive organization to post publicly asking for help on how to parse our conversations.

If the technology cannot provide unlimited for customers who have paid for it, then unlimited service should not be sold. Simple as that. Anything else is inexcusable. If the technology stack can only handle all customers at 250 kBps, then that is the maximum service they should be selling.

"We can handle 20% of users at 5 Mbps, and the other 80% at 250 kBps. So we'll sell the 5 Mbps. But we won't restrict sales to 20% of customers, we'll sell to as many as want it and then throttle to handle overloads on the system." There is no way to make this situation acceptable. Don't sell what you can't provide. Pretty fucking simple.

Unlikely they'll squeeze more linodes onto a physical machine. The overhead being saved isn't that enormous. Not to mention there might be more CPU, but there isn't necessarily enough memory, disk I/O, and/or network available to make it worth it. I wouldn't worry. Plus linode has a solid track record of improving user experience, not putting it at risk. If they find a way to squeeze in a little more, you won't be losing any performance.

Honestly the only problem with your scheme has been sharing it. If your hackernews account can be used to find other accounts of yours online, you've just made writing a custom brute force script for your accounts much easier.

I imagine you've done more than most people who customize passwords based on the site/domain name, but you should never share the specifics of your algorithm. It reduces brute force effort against you from nearly infinite to possibly hackable.

Another pain point is the delay from Friday's discovery to Monday's disclosure. While it's better than the sometimes weeks other companies have taken, it screams of the discovery happening at 4pm on a Friday, and everybody then saying "bah fuck it, go home for the weekend, we'll work on it Monday". A security compromise like this should have been made known by Saturday at the latest, and worked on over the weekend. 3 days is a long time for leaked passwords to go unnoticed to users, regardless of the encryption scheme being used.

And if you want to scrape a list of Facebook usernames to use with this, Facebook makes that easy too: https://www.facebook.com/directory/

It's against the ToS to do so, but of course Facebook is willing to expose all that information for anyone willing to break the rules.

Well-intentioned or not on your part, I would quit my company if they required me to input my opinions into such a tool. With only 10 devs, it is instantly possible to match any downward trend to a specific individual based on keen observation, and then penalize (no raise, no promotion) or even fire/lay off that person for not "fitting the company's core values".

Because of the possibility for abuse, chances are high that some/many of the inputs are pure bullshit anyway - people saying they're happy when they're downright miserable, out of fear of being scoped out if they log negative results.

Just another management PR stunt so they can gloat about how happy their employees are, when the results may be fabricated. Perhaps this would work in a small company where downward trends in happiness result in immediate changes based on employee suggestions. For every medium and large sized company I've worked for, this would just be another manipulative game pushed onto employees by management who will never implement any real change but can show the CEO ridiculous charts about how "happy" the employees are.

tldr; Management loves to show off reports like these, but the values input are often meaningless and only serve to antagonize employees rather than help.

Testing the filesystem? This talk is interesting as hell, outlines how FoundationDB goes about testing unusual failures in systems like the filesystem and the network stack: https://www.youtube.com/watch?v=4fFDFbi3toc . Crazy beyond all belief.

I'm also not a Stripe customer, but back when I went to check out how it worked, the most impressive thing was being able to skip the sign up and jump directly into a usable product. Spend some time setting up your account. If you like what you see, and only then, provide your email and password to create the account (of course keeping everything you've set up).

It's such a simple thing to do on the backend, and yet I'd never seen this before. So simple to implement, but gives an amazing first impression.

However, the things you love about Stripe - like its ease of integration - likely come from the same dedication to quality and user experience that went into the design. Amazing UIs are often an indication of a well-thought out product in which a lot of time went into all the details, including UI and functionality.

A product that cuts short on presenting a polished product on the outside, may very well have the same ugliness to its internal components.

Or, as sometimes happens, 90% of the effort went into the design, and the product itself is crap. That happens too. ;)

Ugh. Before the advent of CSS3 and canvas, I would have rated myself an 8 out of 10 in terms of "frontend knowledge/skills" compared to other frontend developers I'd met. I was never the cream of the crop (as a backend "expert"), but I could take a photoshop and replicate it, and knew most of the browser compatibility issues and how to work around them.

With all the CSS transforms, animations, canvas, 3d libraries, etc., I'm now utterly lost. I've gone from being an intermediate frontend guy to a 6/10 on the core necessities (all that earlier knowledge is still the foundation), but like a 1/10 or 2/10 with all the new stuff. I could probably get to 4/10 if I put in the effort, but I have a very strong gut feeling that I simply do not have the... faculties... required to be an intermediate frontend guy in 2015.

All that to say... codepens like these I've seen blow me away. I don't even bother trying to dig into the CSS. It's just beyond me. ;)

Or the employer heard what they wanted to hear.

Employer, start of project: "Oh, it'll save time? Great!" Employer, end of project: "You said it'd save time, lies!" Developer: "I specifically explained how it saves time in the long run. Not the initial implementation." Employer: "..."

Technically these issues are solved with what I indicated is always missing: time. What you outlined is accurate: proper testing also requires proper planning for tests. For more complicate projects, you don't just start writing them without mapping out everything that needs to be done - and how to go about it. And yes, when code changes, more time must be invested into refactoring the tests.

This disastrous ecosystem exists with QA too (which is again, a form of testing). A lot of companies - usually the smaller ones - don't invest any resources at all for QA. Others just do point-and-click smokescreen tests that'll discover bugs that are blatantly obvious (also typically the ones the developer should never have committed to begin with). Real, proper QA? That requires investing serious time into test cases - completely figuring out every possible interaction and scenario that can take place. All before a single actual test is run. And similar to unit/functional tests, QA test cases need to be reviewed whenever the smallest bit of functionality changes.

The reality is that most employers who "want test cases" want there to be a magical solution that gives all the benefits, without any effort.

To expand on the point "Chrome integration", the most useful aspect of Postman is the "Postman Interceptor". You can clone any real in-browser request (primary page or ajax request) into Postman, ready to be replayed or modified then replayed. The amount of time saved when you're playing with ajax requests rather than a REST API is insane.