fourneau

Looking at their raw data, it looks like there was a total of 718 respondents (https://docs.google.com/spreadsheets/d/1Km9bsx0SWPDiOPMYvrem...).

Large enough sample to be ultra conclusive? Not really, but I think it gives you a taste for the data and it's unlikely that tech interns /do/ make more than most, but it's not really surprising.

"Weaponized OCD" is my new favourite way of describing bad code reviews.

As for people taking things too personally (you or otherwise): talk to your team members. Let them know that you perceive their comments as harsh. If you can't come to a consensus about tone, content and voice, then code reviews will always be a friction point between you and your team. Work it out with them, they're all just people with emotions too, after all.

As for the appreciation of code reviews: developers absolutely hate doing things without reason. For what reason does your team do code reviews in the first place? Is that reason unanimously understood? If not, then you'll face a lot of resistance.

In short, get everyone on the same page as to /why/ you want to use this tool (code reviews) and on the same page as to /how/ to use it.

--

also general code review advice:

- Don't make it all about style, and if you do, preface that you're nitpicking. automate everything you can when it comes to style.

- Use unambiguous questions, with detail. Set a high bar of quality for reviews by leading the charge yourself and holding others to that standard. Don't be afraid to preface questions with: "I don't think I understand how this works."

- Don't be afraid to applaud really cool things as well. Code reviews don't have to be negative comments only.

There are a ton of reasons.

For example, it could just be that ML is not your business. If you're a image hosting platform, you don't necessarily want to build your own NSFW image checker. There's no harm in leveraging something else out there that works great, assuming that you can bankroll it.

Alternatively it can be used as a stop-gap. You're in the middle of implementing your own ML system (or planning to), but you can use a 3rd party to fill the gap until you're ready to go live with your own version.

This is also a great way to test new features and see if users respond to it.

In my opinion it boils down to if either you need to own the model, or guarantee the quality of it, then perhaps you should consider owning it yourself. Otherwise, it's fine to consider using a third party.

With automatic provisioning/specific profile mode, they definitely removed a lot of the sharp edges when it comes to provisioning, but they also removed all of the flexibility. It definitely feels like Xcode on training wheels with no option to remove them unless you rely on a now deprecated feature set.

As much as I disagree with the author, the reason why RMI is brought up is to highlight the next point of "Silicon Valley Hates / Ignores Politics". I think the difference in applicability is understood, otherwise this would be a really naively written article...

> So you could argue that the “RMI/RSA” is basic income, except maybe for the paperware frictions that it inflicts on those who are eligible and that could be removed thanks to technology. Accordingly, those in favor of basic income should pay attention to the “RMI/RSA” and draw appropriate lessons: it’s not simple (at all); it has adverse economic effects; and it is widely denounced, notably on the right, as “assistance” (assistanat) that deprives those who claim the benefit from any incentive to look for a job, thus making them live off the middle class taxpayers. If you know politics, you can guess where this is going. Unfortunately, politics is not Silicon Valley’s strong suit.

It's not that you have less context, as much as you /need/ less context. Instead of a few extra words to describe something, you get a different character.

Here's a great example of how in writing you can disambiguate "aunt"/"older woman": https://twitter.com/MaggieSensei/status/765769637372030977

In the above example all three are read as おば (pronounced: oba). When spoken you still need to differentiate, but it'd either be obvious from context or you'd just explain it manually.

The way I see it is that it boils down to: how likely will the employer greatly surpass your asking price? If the likelihood is low, you should lead. If the likelihood is high, then you should let them lead.

In my opinion, with negotiations, (as much as people hate negotiations in this thread) nothing ever generically applies as not all people are expert negotiators... (including this advice I guess...)

It depends what kind of recruiters you use. At the end of the day, the company that hires the recruiters (whether they're in-house or an external company) should be fine tuning the recruiter's filtering system. With enough patience and direction they can be excellent to find high skilled individuals who are looking for a new job.

Is that... normal? 2350 feeds seems like an astronomical amount of news feeds. Can I ask how much of that do you read?

"Wired doesn't care about you." isn't true at all. Just because a person who is blocking ads may not generate any revenue directly, they may share the article with someone who doesn't block ads.

Losing 20% of their audience may have really painful effects on their reader network.

A few of us on a team started using Triage. We included our work GitHub and someone added a private Stripe account... then we found out that all of the accounts are accessible by everyone sharing the same work e-mail suffix.

Can we unlink accounts now? We've revoked the API keys for the services that we didn't want to share, but they still show up.

One of the biggest detriments to interface builder is the lack of code review. If you're a solo developer, you can maybe get by without this... but for a team that actively follows a code review process, nib files are black boxes with no searchable history.

Out of curiosity, have you maintained any of your large projects over a long period of time? Did you have any issues with nib files (i.e lots of duplicated bugs? re-introduced bugs? etc?) Personally I've avoided nib files like the plague because of this, but I'm curious as to how others deal with them.

This is awesome on so many levels, being a youtube-taught guitar player, this is right up my alley.

Two suggestions: Definitely make scroll speed a setting (similar to how Rockband 'difficulty' is just them spacing things out further to make it harder) and maybe a slower example? A slower example might be friendlier to new players / more welcoming?

Edit: Also, when I signed up and checked out all the tabs... I ended up getting 'Video not available'. Not sure if that's regional settings kicking in (i.e Canada gets nothing)...

Unfortunately not. You can only upload 5 images per device type (iPad / iPhone) and one description.

In theory, you can play the language game and change your descriptions radically based on language, however that's not exactly a valid experiment.

That would lead me to believe that it's 'Tesseract OCR, but in Javascript!'. I think a more substantial name change will be required because of how prominent Tesseract is.

What about the mention of how long it took for 2.1 and 2.2 to actually roll out, after their official releases? I know in Canada, we were delayed for several months as Rogers and Telus took their sweet time pushing the upgrade from 1.6 to 2.1...

Sure you may say "77% of devices run the latest versions" but you may be in the situation where "0% of the devices in your country run the latest version" because your carrier isn't updating the OS.

That's the fragmentation I'm afraid of.

Either way, it'll be a great learning and prototyping tool. Not to mention it's great to see some interesting web development tools that offer a little more than code completion/syntax highlighting.

Hopefully Adobe carries this through to a product (or even better, a free tool?) and doesn't let it die as a prototype.

It's not always as easy as dropping support for older devices/OSes. When you have to support older systems (for client requirements, as an example), it goes from a "tiny bit of extra work" to "a tiny bit of work and a whole lot of extra testing". Just adding a single different type of device (i.e. supporting Blackberry Bold and Storm) almost adds twice the testing effort.

I'm not trying to say that developing for resolution independence is extremely difficult... but it's no walk in the park; it takes time. You truly have to ensure that your application can run on a wide gamut of devices and that the user can interact with it appropriately.

My review:

1) As you already know, landing on the page is very harsh. The very first thing I saw when I arrived at the page was a popup that asked me to sign in with Twitter or Facebook. I didn't really read the title or the text; I immediately pressed back. This is easily fixed by letting the user know what you are before signing in.

2) Switching between sites is really well done, I instantly understood how to do it.

3) I dislike the "I like this too" button. It's not clear with what it does; I clicked on it hoping for a "post to Facebook or Twitter" option but it went straight to my Twitter. I'd prefer having two separate buttons to know exactly what I'm doing.

Overall, neat idea -- but it feels like I'm being tricked into doing certain actions since I don't quite know what's going on at first.

Captchas like these make me wonder if I'm a robot...

I was a big fan of this new captcha idea until the video.

I'm really glad that JDK 7 finally has diamonds. (In more ways than one: http://weblogs.java.net/blog/forax/archive/2009/08/27/diamon...)

Anyone interested in starting something similar to this in Ottawa, Canada?

Without complicating the service at all, I would love to see Dropbox integration. We use Dropbox for all of our shared files and being able to go from: Whiteboard->Email to Service->Dropbox immediately would be amazing.

That's both hilarious and frightening all at once. Luckily static analysis tools catch that kind of stuff very easily now...

I find that most, if not all, of the shortcuts on a Mac are confusing. Sure, the icons don't help, but it's even worse when there's no visual indicator.

To this day, I still don't properly remember how to take a screenshot even after using the system for over a year. It's not that I don't take screenshots, it's that I have to form a mantis with my fingers to actually use the shortcut. That really makes it difficult to remember. In the end, I ultimately mash a combination of command, shift, option and some numbers and I hope for the best.

Yes, the point of Gitbox is to hide the details but that's not necessarily a bad thing.

I've had to teach plenty of people how to properly merge files using Git and no one has ever said "oh that makes sense". If a tool can hide the ugliness of merging conflicting files, even a little, it'll help a ton of people get used to using Git.

Memset (according to the c++ reference) is supposed to: "Sets the first num bytes of the block of memory pointed by ptr to the specified value (interpreted as an unsigned char)."

So, give it a pointer to some memory, give it a value and the number of bytes you want to set and it'll go wild. In this case, memset was just blindly dropping in zeroes into the memory block