nfm

UsabilityHub | Melbourne, Australia | Senior Software Engineers | Full-time | Onsite

UsabilityHub is hiring senior engineers to join our team in Melbourne. If you’re not familiar, we help businesses (including Amazon, NASA, and Reddit) be more human-centered by making user research easy to conduct and fun to participate in.

We’re a bootstrapped, profitable, and sustainable company, with a focus on building great products, not chasing growth for the sake of it.

Ideally you’re a generalist who is capable across back-end (Ruby, Rails, Postgres) and front-end (Typescript, React, Redux, Webpack), but if you specialize in one area and are still getting up to speed in the other, don’t let that dissuade you from applying. It’s more meaningful to us that you’re a great developer and a keen learner.

We’re offering…

- $120k AUD base salary (FTE) + super

- the option to work 0.8, 0.9, or full time

- the option to regularly work from home

- generous paid parental leave (14 weeks primary / 6 weeks secondary)

- profit share scheme among employees

- a warm, friendly & relaxed team

For more info, and to apply, see the full job listings: http://bit.ly/2MK9Zrk

The data isn't lost, but it's not straightforward to query if you don't have a record of it in your own database.

Eventually you'll want to find out what your resubscribe rate is, or what the average interval between subscriptions is. Answering these types of questions via Stripe's API is no fun.

UsabilityHub | Melbourne, Australia | Senior Software Engineers, Senior Product/UX Designer | Full-time | Onsite

UsabilityHub is hiring senior engineers and a product designer to join our team in Melbourne. If you’re not familiar, we help businesses be more human-centered by making user research easy to conduct and fun to participate in.

We’re a bootstrapped, profitable, and sustainable company, with a focus on building great products, not chasing growth for the sake of it. Our product team (currently one senior developer and three technical founders involved in the product) works efficiently using modern practices and tooling, and together we get a lot done, despite everyone choosing to work a 4 day week.

Ideally you’re a generalist who is capable across back-end (Ruby, Rails, Postgres) and front-end (Typescript, React, Redux, Webpack), but if you specialize in one area and are still getting up to speed in the other, don’t let that dissuade you from applying. It’s more meaningful to us that you’re a great developer and a keen learner.

We’re offering…

- $115k - $125k AUD base salary (FTE) + super

- the option to work 0.8, 0.9, or full time

- the option to regularly work from home

- generous paid parental leave (14 weeks primary / 6 weeks secondary)

- profit share scheme among employees

- a warm, friendly & relaxed team

For more info, and to apply, see the full job listings: http://bit.ly/2MK9Zrk

In principal, I agree. I'm certain Slack has run the numbers and decided the ROI of implementing cross-browser video calling is lower than whatever else they're investing engineering time into. Sure, they have a lot of capital, but it's a large undertaking. A vocal minority of Twitter users shouldn't sway this.

In practice, it's pretty lame that they've had voice calling for almost two years, and this has never been available in Firefox. We're not talking about old IE here. A basic implementation of voice only calling is not hard to do.

Not really. It's hard for your editor to do this statically, but there's heaps of good tooling for finding the method source and docs dynamically.

  pry> show-source SomeClass.class_method
  pry> show-source AnotherClass#instance_method
  # List an arbitrary object's class methods, instance methods, methods mixed in by included modules
  pry> cd some_object
  pry> ls

The runtime knows how to execute your program (it's not random) so everything you want to know is available.

The difference is that you can push a tab from one device to another. So if you're reading something on your phone, and push it to your laptop, it will automatically open in a new tab there once it syncs. It's good for when you're on the go, and want to remember to read something later on once you get back to your computer.

By the way, Firefox also has the feature you mention (view tabs that are open on devices).

> It's only kind of open source, and only partly.

That's a pretty misleading characterisation. You can browse the source code, submit issues, see what's being worked on, contribute PRs, and freely download and run your own instance of GitLab. A handful of enterprise features aren't open sourced.

GitHub in contrast is a black box.

I really disagree with this.

Google has extremely strict safeguards in place to prevent eg. employee Joe from accessing ex-girlfriend Mary's Gmail. Very few people would have full access to individuals' Google accounts. This kind of privacy breach would be very damaging to Google.

Niantic is a tiny startup with around 50 employees. I would expect most developers within the team would have full access to the production database, or would be given access if they had a need for it. It's unlikely that there's any oversight over who can access data - it's just a 'game'.

Where are their backups stored? Are they encrypted? Who has access to the decryption keys? We don't know, but I would bet any amount of money that their systems are vastly less secure than Google's are.

The relationship between Google and Niantic isn't relevant as to whether they are capable of keeping these credentials secure.

I'm not sure what you mean about changing the JSON structure; the Stripe API is versioned and you have to opt-in to any updates, including breaking changes like removing or renaming keys in the response.

The rationale is also explained in the policy:

Ubuntu is a trusted open source platform. To maintain that trust we need to manage the use of Ubuntu and the components within it very carefully. This way, when people use Ubuntu, or anything bearing the Ubuntu brand, they can be assured that it will meet the standards they expect.

I think everyone would agree that the above commit history is bad, and should be avoided.

But solving that issue by adopting a squash-on-merge policy is like doing surgery with a chainsaw. There are better tools for the job.

Most of those advantages aren't microservice specific - they're just a function of well factored code.

Doesn't look too bad, although there are a lot of CVEs to go through:

- A timing attack if you're using HTTP basic auth

- A couple of GC related DoS attacks

- An issue with `accepts_nested_attributes_for` if you're using both the `allow_destroy` and `reject_if` options

- A validation bypass exploit if you're calling `SomeModel.new(params[:some_model])` instead of using StrongParams

- An information leak exploit if you're calling `render params[:something]` with raw user input

- A bunch of potential XSS exploits

The `render` issue looks like it could cause the most harm, but hopefully shouldn't be too prevalent. The XSS issues should be a quick fix as you only have to update `rails-html-sanitizer`, not Rails itself.

For what it's worth, I'd definitely prefer logins from new devices to require an email confirmation when 2FA is enabled.

Yes, yes it is.

Does the link work as expected for you?

The strange thing is that it does work for me if I copy-paste the link (as opposed to ctrl-clicking it). There really shouldn't be much that's different between those two requests except for the referrer header.

That link is redirecting to an unexpected image for me.

Edit: it works if I copy-paste the URL.

What webserver are you using? Running puma in threaded mode, even on MRI, should allow your external API calls to run in parallel - this might simplify things a bit :)

Nice work :) And the migration process (http://v4-alpha.getbootstrap.com/migration/) doesn't look to be too hard, either.

The warning is a bit annoying, but without it attacks like this would be harder to spot: http://feross.org/html5-fullscreen-api-attack/ (it's just a proof-of-concept, no malicious payload)

FUD! https://developer.android.com/about/dashboards/index.html

Only 5.9% of Android users are on obsolete 2.x. 5.1% are on 4.0.x, for which Chrome was just EOL'ed at version 42 (http://blog.chromium.org/2015/03/freezing-chrome-for-ice-cre...), which compares very favorably to the current and previous versions of Safari (http://caniuse.com/#compare=chrome+42,safari+7,safari+7.1,sa...).

This is unlike Stripe but this landing page is totally broken in Chrome and Firefox on Android for me: https://www.dropbox.com/s/axl4ogngkmdtc83/Screenshot_2015-06...

Do you think that's a problem that can be solved generically by the browser? It seems infeasible to me.

Yes, I had no idea the email field isn't publicly visible. Thanks for the heads up :)

Paper ballots tend to work. There have been significant screwups though: http://blogs.abc.net.au/antonygreen/2014/02/wa-senate-re-ele...

Given that we're generally happy to trust online banking, my feeling is that there is a way to make electronic voting secure enough. Where you want to draw that line is subjective though!

Depending on the era and location, slave labour totally skews the calculation too.

The merge example that introduced a logical bug in the article was only visible in the diff because the bug occurred within 3 lines of the added line in the feature branch.

The best way to avoid this issue is automated testing. The second best way is to crack open the file itself, and review the entirety of any functions that changed. Even that approach assumes your encapsulation is nice and you're not introducing issues based on global state though.

While the BitBucket diff is better than nothing (and better than GitHub/GitLab), it's not sufficient to avoid these kinds of issues entirely.

I think the author's point was that the example in question was orders of magnitude smaller than "big data" and that it was more efficient to process it on a single machine, not that Hadoop and friends aren't easy to use.

Sorry, I don't think I was very clear. That's exactly what I meant. They didn't make a performance based decision when choosing their stack, and now that they're a huge site they're doing just fine - no need to go rewriting in the latest 'performant' stack.

I don't think there's much point nit-picking on multiples - who knows for sure without seeing their code - but my point still stands. Would you have been surprised if StackExchange ran on 50 or 60 front-end servers? I certainly wouldn't have. And that would be the equivalent of being able to take 200ms a response for the same amount of traffic. In ruby/rails that's a pretty horrible end goal. GitHub's mean web response time is currently 57ms, for example.

Yeah that's my point - if they were using a slower language they'd be clocking in at say 20 or 30 servers. Not remotely worth optimizing for saving that many servers at their scale.