killing_time's comments

It's pretty straightforward: you either click on their profile or (if you know someone's username@server via some other medium), search for them on your 'home' server and you'll see their profile. Then just click the 'follow' button.

Under the covers this sets up the federated follow relationship, but the UX feels the same as following someone on twitter.

There is one slightly more complicated scenario; if for some reason you're exploring a different server and find someone there you want to follow. In that case you still click the follow button but have to provide _your_ username@server string which triggers the necessary back-and-forth to get the follow relationship set up.

Skyscanner | London, Barcelona, Edinburgh, Budapest, Sofia | ONSITE, VISA | full-time senior hires

We're one of the biggest travel metasearch products in the world by traffic... and we want to 10x that :)

Hiring at mid to senior levels in lots of key disciplines: backend with microservices & distributed systems, big data & data science, full stack and frontend, designers, product, iOS & Android. We are growing in all of our European offices - in particular, London and Barcelona.

Our tech stack includes Java and Python for backend microservices, JS (React) for frontend, and we're deploying with Docker and Kubernetes on AWS. If you're experienced in these technologies, you'll find interesting challenges to work on and solve, as part of a great team.

I've been here for a year (one year today!) and am really enjoying the breadth and depth of the work, the quality of the people, and the amount of care that the company takes to give us a comfortable and productive working environment.

You can see our current open roles and apply at http://grnh.se/jitlcd1 - or ping me an email at richard (.) north [at] skyscanner.net for a referral. I'd be very happy to answer questions or pass you to someone who can.

How about Cloudburst?

I use the Chrome and Firefox docker-selenium containers in Testcontainers [1][2], my project for running containers to support JUnit tests.

I created this after numerous issues with PhantomJS compatibility and debuggability; Testcontainers instead uses the real browsers, and also offers automatic video recording of test sessions and VNC access for debugging.

Headless chrome support sounds like a good step forward, but if visibility into what's going on is limited then I feel there's going to be some way to go. Perhaps chrome remote debugging support?

[1]: http://testcontainers.viewdocs.io/testcontainers-java/ [2]: https://rnorth.org/26/better-junit-selenium-testing-with-doc...

Developer here! This library arose out of frustration with running Java tests that had some kind of non-Java dependencies - e.g. databases and web browsers for UI testing. Testcontainers lets you add Docker containers to your tests, linked to the lifecycle of the test rather than having to be externally managed from the outside. I've found it useful, and hope others do too.

A few blog posts outline some of the ways the library can be used:

* JUnit integration testing with Docker and Testcontainers [1]

* Fun with Disque, Java and Spinach [2]

* Better JUnit Selenium testing with Docker and Testcontainers [3]

[1] https://rnorth.org/24/junit-integration-testing-with-docker-...

[2] https://rnorth.org/25/fun-with-disque-java-and-spinach

[3] https://rnorth.org/26/better-junit-selenium-testing-with-doc...

I'd be really grateful for one if you still have any up for grabs. My email address is in my profile. Thanks in advance

Yeah - the very earliest preview versions of Meteor had this obvious gap where reads and writes were basically a free for all. However, it's changed a lot since then. As a development crutch the aptly-named 'insecure' package is installed by default (which maintains the free for all), but you're expected to remove it and able to apply fine-grained control to which clients can C/R/U/D which data.

These two steps of the Meteor tutorial probably describe it best: https://www.meteor.com/try/10 https://www.meteor.com/try/11

Specifically about this issue, see the section about the MongoDB oplog further down in the article. This removes the polling interval/overhead, so should significantly improve performance and responsiveness.

Argh, please, no.

Over time I know the term 'native' has been used for many things, but I'm pretty sure the most recent peak in usage started with the iPhone SDK, where it meant 'apps which aren't based on a web browser'. Since then, I've wanted _so much_ for web technologies to become the best platform for making apps, but the hard truth is, they're not. With 16 years more web experience than iOS, I'd still rather shoot myself than use web technologies to make an app with the same UX quality, maintainability, and development time I can achieve natively.

I'm pretty sure the native vs hybrid argument has been settled - for now, though I'm always keen to see new developments.

Seeing software vendors and articles like this pushing to use the term native to describe _the very thing which is not native_ seems a little sad and desperate at best, and an attempt to confuse at worst.

For testing ansible playbooks/roles in a vagrant VM, I find a simpler way is to use Vagrant's built-in support for Ansible as a provisioner.

This way, launching your test VM is just a `vagrant up` and running ansible against it (repeatedly, if needed) is `vagrant provision`. No need to pass inventory/key parameters at the shell this way - Vagrant calls Ansible with the right settings.

One thing that's easy to miss is to make Ansible use sudo when running against the Vagrant VM, since the vagrant user by convention has passwordless sudo rights (ansible.sudo = true in the Vagrantfile).

http://docs.vagrantup.com/v2/provisioning/ansible.html is a helpful reference doc.

The use case which this really excites me about is automated testing from the GUI level. If the performance is good enough, this would be really useful for restoring DB state in between tests.

This looks pretty neat. I can't believe I'd not heard of it before.

From a quick skim of the docs it feels like it could be the successor to Play v1 I was looking for. Opinionated and full stack, yet pure Java and built on existing, familiar, frameworks so that the average client or developer can feel a bit more comfortable.

I'm looking forward to trying this out!

Pretty cool stuff! I think it's great that this lib is designed with extensibility in mind rather than being tightly coupled to any particular data store. I can see this being very useful for offline sync and reactive UI projects.

Thanks for making this - seems to work with PSDs so that's great. This tool has already saved me a bunch of time this week!

One feature request would be to make the app automatically refresh the overlay when the source file changes, or to have a keyboard shortcut to refresh from the saved file. This would be useful when toggling layers on/off in Photoshop to look at different states of a screen. Cheers!

This looks like a neat tool, with a nice simple solution to a common UI development problem.

What image file formats can be used as mockups?

Yes, having predefined keys in your VM images does the trick, and is exactly what we do for (almost) zero-intervention deployments of our servers in my particular environment.

We tend to destroy and recreate servers more often than we scale out, so we haven't bothered to remove the manual step of adding the server's hostname to the ansible inventory_hosts file. However, that's easily automatable...

Ansible will _execute_ your inventory_hosts file if it's executable, and IIRC it just needs to return a JSON or YML data structure representing all your servers and the groups they're in. So, as long as you have a library which can query your infrastructure (e.g. boto for EC2 etc) it's not hard to automate this.

Link: https://github.com/progrium/dokku

It's probably also worth mentioning dokku, which is a simplified private PaaS built on top of Docker. It adds Heroku buildpacks (Ruby, NodeJS and Java right now) into the mix, and a git push-to-deploy model.

Because dokku has a concise and readable codebase, browsing the source is a good way to see one practical application of Docker, too.

I've set it up as a sandbox environment for developers at my company, and for our purposes it's a much better fit than some of the more heavyweight private PaaS products. I'm really enjoying working with it!

Whatever you do, don't think about getting hit in the face by a helicopter...

Looks great - nice work!

Looking forward to taking some time to properly look into this. Would I be right in thinking that there are some scenarios which won't work out of the box, like offline edits? Or does SDScaffoldKit add some extra magic to cater for this?

Thanks for putting this up!