room271

Nothing amazingly innovative, but I've used it a lot at work. For simple jobs/event processing it is amazing as it removes a load of complexity (logging, monitoring, scaling, deploying).

Lambdas tend to be < 100 lines of Javascript which means maintenance and rewriting is trivial. And because the jobs are so simple people don't need to be Javascript experts or aware of the JS ecosystem to write them.

Lambda is also very cheap if you have bursty or just very low-volume workloads.

Yes, for the things she describes her manager should have been fired, not kept on after some kind of apology.

A simple solution if you are in AWS is S3 with instance profiles for access.

Re 2: I'm not sure if you're trolling here. It's a fantastically complicated question and the economics has barely scratched the service. Strong proponents either side here, but there is certainly a lot of research linking inequality to poor social outcomes (higher crime, poor health) which in turn we tend to think negatively impact growth.

That sounds like a terrible strategy for a lot of us, where time to fix is much more important than bug count.

This is because there is likely to be a tradeoff between speedy development and bug count.

If you are shipping physical CDs of software, or releases which you can't update easily, or if you are working in a critical environment where mistakes are disastrous (finance, health, space, etc.), then it is fair enough to be so concerned about bugs.

But many if not most developers work on the web in areas where the product is uncertain and evolving. Prioritising rate of change is more important here. Rather than extensive QA, monitoring and fast rollback are better choices.

There is a common idea in economics that explains the problem with what you say: externalities. This is when my behaviour affects you in a way not captured by the market.

For example, if a forest is privatised and cut down the owner might be acting in their best (market) interest, but people living nearby will be negatively affected.

We could try and put a price on these negative effects, but it's very difficult so the better solution is normally to keep things private.

Essentially, you're arguing the solution to one set of externalities is to privatise, but that very privatisation will create a whole host of even worse externalities.

We see with climate change and carbon emissions that ensuring companies pay for their externalities (pollution) is very difficult post the event because there are strong vested interests against this, and the people affected negatively are many but spread out, there is little incentive on an individual level for them to go to the vast effort to fight against the polluter.

You have to balance the value (which I think to be honest you overstate - how hard is it really to find somewhere with safe and clean food that you like) with the costs. On the latter, I am mostly thinking of the health effects of their food.

Slight correction: the author suggests not drinking juice at all (instead eat fruit directly). But if you do want juice, then make it yourself.

One question related to AWS is how to, or whether it is worth, segmenting access to resources for containers. If you are using single instances for each service you can use instance roles for this. These are great as they are temporary, tied to the machine, and most of the client libraries will detect them automatically.

If you are using containers, you need to create proper users presumably. Or you need to give all the permissions to the instance.

Maybe this isn't a problem in practice because people group related services together into separate orchestration clusters (i.e. a Kubernetes for each service grouping).

But it would be great to hear some real experiences on this.

'contenteditable is inconsistent across browsers'.

We (the Guardian) created Scribe to tackle this:

https://github.com/guardian/scribe

(I can't take any credit personally though alas!)

It says it is not very good. There are a lot of problems with Cloudsearch. By contrast, Elasticsearch is great and not too difficult to run yourself in AWS, or indeed elsewhere.

Aside from product differences, Cloudsearch was phenomenally expensive, particularly if you had a larger dataset but low read/write volume, as Cloudsearch did not use EBS (at least not in a way you could control), unlike RDS for example.

As far as I understand it, Taler seems to be great for privacy and society (ensuring income is taxable). Governments can't see how you spend your money, but they can see who receives payments.

Bitcoin and others will never succeed because they are too friendly towards illicit behaviour. Taler seems to strike a genuinely interesting and ethical balance here.

I have a (genuine) question about this, as I'm interested. What is the benefit to supporting so many ways to instantiate a File object:

    val f = File("/User/johndoe/Documents")
    val f1: File = file"/User/johndoe/Documents"
    val f2: File = root / "User" / "johndoe" / "Documents"
    val f3: File = home / "Documents"
    val f4: File = new java.io.File("/User/johndoe/Documents")
    val f5: File = "/User" / "johndoe" / "Documents"
    val f6: File = "/User/johndoe/Documents".toFile
    val f7: File = root / "User" / "johndoe" / "Documents" / "presentations" / `..`

Why not just the first one, and string interpolation/composition if you need 'root' or 'home' ?

The Guardian | LONDON | ONSITE

Looking for fullstack or server-side devs interested in working on APIs and related tools using JVM languages (Scala at present) on AWS. The work is really interesting and the Guardian is a great company - both from a tech perspective because of our scale, and because of the journalism we do. I head this team from a tech side so any questions get in touch! (nicolas.long@theguardian.com).

More details here (ignore the technology list - more important is good ideas and a willingness to learn):

http://underscore.io/jobs/2015-05-20-guardian-discussion/

I've used this and it's great. Very easy to use and works.

For priorisation of stuff: Monitor metrics that relate to end-user experience (i.e. latency, http exceptions, or whatever makes sense for your service). There are lots of tools to do this kind of thing, and in particular to aggregate it at the service level. If you see those metrics significantly change you can then investigate lower-level problems that might explain what you've observed (i.e. exceptions, or other software, hardware, or network problems).

But also, and I agree with other people here, your app shouldn't really be throwing exceptions that are uncaught full stop (unless it is not user-facing or that important) so it's worth fixing that too. (Unless you are writing Erlang or something where the failure model is different.)

This. The key thing missing from Fowler's blog post is context. If you are a small team/company then microservices is probably not sensible unless you are highly skilled - the overhead is too high and the benefits less too.

If you are a bigger organisation though, with lots of teams, microservices are required to decouple teams and enable agility/exploration in products and services.

Lastly, it's easy to advocate the monolith ('only to start') when you're a consultant, as you've left by the time it becomes a problem. Or, you get called in down the line when it's all gone pete tong because the monolith 'prototype' has become a monster.

Note, I've spent the last two years working on microservices (which has involved a big learning curve but now yielding benefits) and also old monoliths (that have sucked up so much time it's unbelievable).

Something that I think gets missed often from these discussions is the idea of different definitions of 'senior' in different contexts. If you're working at Google on search algorithms, it doesn't matter how good a communicator you are, if you aren't technical enough to understand the work and think about how to improve it, it's not much use.

Conversely, if you're a brilliant architect but aren't great at being very pragmatic and hacking stuff out, you might not add much value to a lot of smaller webshops.

So someone who would qualify as senior in one place, wouldn't be very effective elsewhere.

And as developers, we can try and identify our own interests and skills and find work that fits these.

I've seen the author (Noel Walsh) talk on Scala a few times and he's a great teacher. And also good at showing how far you can get with just ADTs, structural recursion and objects as namespaces for your functions. This, in my view, represents a great, functional, subset of Scala. (Avoid normal classes, mutable state, etc.)

I worry media companies are effectively in this position with regard to social.

Really? I'm no expert on this, but it seems like the Guardian game journalists have been pretty transparent they don't like the GamerGate movement.

People are giving surprising answers here. But it is really quite simple:

- do you think the company did something wrong?

- do you want to help discourage other companies from doing the same thing in the future?

If the answer is yes to both, then you should testify.

The truth is, no one here has a crystal ball that will tell them the impact of testifying on your future. In life, you sometimes have to just go with what you think it right.

Ask people. The best way to ground your perspective is to ask your colleagues (and boss) clear questions about how they think you are doing and how you can improve.

Obviously do this in private as, unless you have an especially open team, people are unlikely to give honest feedback in front of an audience.

Seconded! Had to restart my browser :(

Thing is, if you own one of those houses, which is true for a lot of the older generation, it's pretty nice.

Of course, if you're not rich and trying to get on the housing ladder now, things are pretty difficult.

Your binary divide between worthy homeless and unworthy is simplistic. Why, for example, do some cities have far more homeless people than others.

The high number of homeless people really struck me when I visited San Francisco a couple of years ago, and it's worth as a city asking why. For a wealthy place, it was incredibly sad and surprising too.

So I agree that is a provocative essay. A more generous interpretation of what the writer means might be:

- a broad social interaction is vital if are to lead enriched lives, and also if we want to help others

- a genuine intellectual mind is one which is curious about learning in varied forms (in point of fact, a lot of good programmers are musicians too)

Now, even if you agree with the above, it doesn't follow that programming is especially bad compared to other ways people spend their time. Playing Farmville all day, as you argue, is not likely to be conducive to the good life or society either. Not that either hacking late at night, or Farmville are bad - it's more the point the article makes about addiction I guess, and lack of balance or outward-turning in our lives.

Sounds like a load of pretentious waffle, but hopefully some of that makes sense or conveys some of what (I think) the article is saying.

I agree with the point about cryto, but I'm not sure your general point about society being unable to contain anything is sound.

Guns are controlled in many countries quite effectively. Not completely of course, but compare for example gun crime in the UK with the US.

There are fewer (if any) examples of drugs being controlled effectively (in non repressive regimes) I'll agree though.

Some advice I've heard in the past: don't be pushed from existing stuff, but be pulled to new stuff.

I.e. work hard to enjoy your current circumstances and only leave if there is a positive pull - something you really want to do - elsewhere.

Ah cool, just wanted to clarify as I'm only a beginner for much of this stuff, but found your posts very interesting.

Thanks!