bobfromhuddle

We don't use CO2 to make cement, we use limestone, and CO2 is the byproduct of heating the limestone to make reactive calcium.

Not at any scale that counts. There are a whole bunch of companies _trying_ to make zero carbon cement, but it's all very early stuff.

The lifetime of a cement plant is 30-50 years, and they cost 100-200M Euros to build, so even if there were a process that was ready to scale today, producing a cement that passed regulatory standards, we'd still be making some Portland cement into the 2070s.

Ergo, producers would like to stick a carbon-capture plant onto their kilns.

Yes! Likewise for grinding: offload excess power to industrial plants so they can grind rocks when it's windy. If you look at the problem in the right way, a silo full of ground rock is just a battery.

I work on decarbonising cement production, and the cement producers are betting _heavily_ on carbon capture as their "get out of jail free card".

I think they're likely wrong, but - again - it's not like we can just stop making concrete: all the solar farms, wind farms, dams, and assorted infrastructure that we need to combat climate change will be made with concrete, and there is currently no viable zero carbon alternative.

The grid is the easy bit, and will happen as a result of market forces, but those hard-to-abate sectors are really fricking hard.

Concrete absorbs co2 while curing. It's the calcination process, where we heat limestone up until the co2 burns off, that has unavoidable emissions. Since this concrete is recycled, that's already happened.

Billions of people do care https://www.carbonbrief.org/interview-why-global-support-for...

The emissions trend is slowing. We have the technology we need in order to change course, we're just not deploying it fast enough.

The worst projections, at least, are off the table: we're not headed for 6 degrees of warming, we're on track for 3, and I strongly suspect we'll end up closer to 2 degrees of warming.

That is going to be terrible. People will die, wars will be fought, and we'll see the largest migrations in human history with all the attendant political upheaval and barbarity, but we'll still be here. Humans as a species are going to make it.

For me, I found it helpful to go and work in climate. So long as I wasn't actively working to solve the problem, I was driven mad by the knowledge that we were heading for disaster.

If you're new to programming, steer clear of design patterns. If you're a working python programmer who's curious about how other ecosystems use design patterns, try https://www.cosmicpython.com/

I'm starting a new job doing exactly these things in order to reduce the carbon intensiveness of heavy industry, specifically cement production. I'm hyped because I think the technical challenges aren't too daunting, and the prize is huge.

And they're free to continue their speech elsewhere. Cloudflare and Voxility are within their rights to refuse service to a client on the basis that the client is persistently associated with terrorism and kiddy porn.

Why is that a remotely controversial statement? Nobody is suggesting that chan-tards should be rounded up for unamerican activities, and I'd be the first to speak against that, but CF don't need to tarnish their brand with 8chans bullshit.

They're free to withhold their support and so express an opinion.

The difference is that every single one of your counterexamples is something that society depends on.

Nobody depends on 8chan. 8chan is not comparable to "air".

This point is so incredibly banal that I'm surprised to find myself making it.

Yes. Reasonable people "exclude the middle ground" on support for domestic terrorism.

Your comments here aren't helping. The clear implication is that Dr Bouman is receiving "undue credit" in order to push a "feminist narrative".

If that's your honest reading of events, then you're the problem here, my dude.

* Email - neomutt + notmuch.

* Chat - Weechat + WeeSlack (https://github.com/wee-slack/wee-slack)

* Pair Programming - tmate.io + neovim

* Google Play Music - tuijam(https://github.com/cfangmeier/tuijam)

I really like bat (https://github.com/sharkdp/bat) as a cat replacement, and I've been enjoying using entr (http://entrproject.org/) for running tests automatically when code changes.

I had issues with depression when I was younger. Self-harm, severe depression, suicide attempts, the whole gamut. Wasn't hospitalised, but that was the next step.

Looking back on it from my thirties, I've come to the conclusion that most of my problem was disturbed sleep patterns, and the rest was unhealthy thought patterns that became self-perpetuating.

Medication didn't help me in the slightest, just made me worse. Getting some sleep and engaging with the world around me is what made all the difference. I'm skeptical of the value of anti-depressants, and some of the side-effects are deeply troubling.

The problem is that when I was in the midst of a depressive episode, I wasn't capable of fixing those things. Telling a depressed person that they just need to think happier thoughts, get some sleep, take a bath, go for a walk is utterly pointless.

Made.com | Backend engineers and Architects | Soho London | http://www.made.com | Fulltime, ONSITE

Made.com is a rapidly growing online platform for bringing high-end design to the mass-market.

We apply ideas from DDD and event-driven architectures in a Python context, and we're looking for talented devs with exposure to event-sourcing, CQRS or DDD in any language.

Top-notch TDD skills are a must; experience with Ansible, Docker, and AWS would be welcomed.

Send a CV to bob@made.com

We use nginx-vts (https://github.com/vozlt/nginx-module-vts) to get metrics out of our nginx servers, and then we send them over to our Riemann stack with a Collectd module: https://github.com/bobthemighty/collectd-vts

The vts module has been updated in recent months to support more granular reporting of request times, but it's had everything we need for a while.

It exposes metrics either as an html page or a json api.

I'm running Arch on a Dell M3800, most of my colleagues are running various Ubuntu flavours on the same hardware. Works well, up to and including the touchscreen.

Battery life is poor compared to a Mac, but it's really light given the compute power.

Heuristics. Really complex heuristics that defy simple codification: the feeling that a particular group of stones just isn't quite safe yet, the feeling that there is weakness in a structure on the other side of the board that can be exploited, the feeling that this corner is too hot right now, so you should definitely extend instead of the hane.

If you're not already a go player, and want to get started, come sign up on online-go.com and ping me, I'm pathogenix.

The same arguments were made about object orientation: I've never needed it, it's useless baggage with no real world benefits, it sounds great in theory but has no practical use...

I've built hypertext APIs, and they worked really well.

We had a(n overly) complex domain model where most of the complexity was around managing a permissions model for access to resources. We tried a whole bunch of ways to represent the actions available to end users, but the only one that worked really well was to advertise a URI when you could do something, and to omit it when you couldn't.

All the nightmarish logic was safely hidden behind the uniform interface. Clients only needed to know that they should follow links, and that the absence of a link meant that a resource wasn't available to them because reasons. It was a beautifully natural mapping of a difficult problem domain into a simple consumption model.

As a bonus, we could change URI structures around when we felt like it, and our clients never missed a beat, because they always followed links from a well-known entry point.

It's not always the right choice, there is plenty of room for simple RPC, but for workflows, and dynamic discovery of resources ReST works a treat.

It's really not, I'm sorry.

State is carried by the client, the client traverses links to find out what it can do, the responses are described by a published content type, and the content type defines the semantics of the protocol.

It's not hard, but people like to pretend that it is. Nothing says you can't stick to GET and POST, nothing requires weird headers.

"ReST in Practice" is a great introduction for engineers.

I don't see much use for this project over, say, Compose, but I use dockerised services for development in my current day-job.

I'm an architect helping to move a a cluster of monoliths to a proper service-oriented setup; some of the teams work in PHP Symfony with MySQL, some work in Python 2.7 with Postgres, some in Python 3.4 with [insert hipster technology here]. We use Redis and Couchbase at various versions for different systems, Eventstore for messaging, and Elasticsearch.

That's a lot of moving parts to keep updated, but because we're deploying docker containers to production anyway, it's really simple to get up and running by just running `docker-compose up` from the root of a project.

tl;dr you're correct, unless you have to work in multiple systems that can version their infrastructure separately.

So much fear and loathing in this thread, which puzzles me. Anyone who sets out to write a hypermedia API in JSON is going to end up with a structure not dissimilar to this one. If this fits your needs, then use it, by all means and let your clients use an off-the-shelf lib for using your service.

I'm not a fan of the spec, but overall it seems to strike a good balance between what is specified and what is left out. To compare this to SOAP is missing the point.

What killed SOAP was an insistence on treating HTTP as a dumb transport - thereby breaking the constraints of the interwebs, the inherent brittleness of RPC, and the lunacy of the WS-* stack.

None of that applies here, it's closer in spirit to AtomPub, which is still a pretty decent standard, but just happens to be in XML which everybody hates nowadays.

I think a lot of the commentators in this thread seriously believe that having a different data format and interaction style for every API on the internet is somehow "simpler" than adopting a loosely defined set of conventions and writing them down somewhere as a standard.

I get the sense that you're concerned you won't be able to keep up with technology trends. This is a non-issue. 95% of what you read on Hacker News is essentially froth, the ephemera of technology. You can ignore it all. The problem is that technology is both your job and your hobby.

I had my first son when I was 22 (now 31), and my career has continued to go from strength to strength. There is adequate time in the evenings, or on commutes, to read and ponder, and I find time at work to investigate technologies that will have a positive effect on the business, because that's my job. Since then I've learned three or four new languages, taught myself a whole bunch of crypo-stuff, got down with the Agile crowd, implemented machine learning and search techniques, and become a software architect.

I think you'd be surprised at how many employers would rather employ happily married young men with children, because they know that they're less likely to be job hoppers; you might be right that early-stage startups are no longer a viable choice, though, unless you're sure they're going to be around for at least a couple of years.

Having said that, I joined my current company six years ago as employee number 5. It was founded by a mid-thirties guy with a wife and kids, who re-mortgaged his house to get the capital he needed.

Having children needn't prevent you from doing meaningful and interesting things with your career, you just need to distinguish between what's important, and what's recreational. After a few months, once you and your wife have started to get a handle on this whole parenthood thing, you'll find more time to do the things you love.

Of course, you might find that you'd rather spend the time playing with your kids :)

I reject the premise that boys and girls are different, at least, prior to puberty. For a kid of 3 years, I contend that they are exactly the same, but that they are treated differently, and that is what makes the difference.

That's a fashionable notion in our post-modern world, but wrong. Young rhesus monkeys display gender-specific toy preferences in line with human behaviour: http://www.sciencedirect.com/science/article/pii/S0018506X08...

Boys and girls are different, though I'll agree with you that most of the pressure to look good is societal rather than innate. Worse: most of it comes from other women.

+1 for this. The first job is to stabilise the system by fixing critical bugs.

As you're doing so, move all those queries into one big fat DB class, and when you spot groups of related queries, split them out into their own classes.

The next priority should be to get rid of the PHP from the DB - if need be create another huge class with a zillion if-else statements.

You need to modify the code to simplify it. You don't need to improve the design, you just need to dumb it down until you can understand where all the parts are. Stabilise, simplify, then refactor.

c# Web developer - London, UK

Senior JQuery, CSS, HTML developer - London, UK

Huddle are hiring in London - we're a .Net shop with rapidly growing user base, and we're currently expanding our dev team to work on our online collaboration system.

We're funded by Matrix, are the leading small company in our space, and are shooting for world domination.

www.huddle.net - mail jobs at huddle.net and tell them Bob sent you ;)

Hate to be the bearer of bad news, dude, but to my knowlege Huddle have a global trademark on the use of the word "Huddle" in relation to collaboration. Would suggest re-considering the name.

IANAL, however, just a programmer.