cantlin

I currently work at GDS, and I don't recognise what you're describing. There are lots of problems, but Java 7 doesn't have much to do with any of them.

Condé Nast International | Software Engineers | London, UK | Full-time | ONSITE, VISA

We make Vogue, Wired, Ars Technica, Vanity Fair, Glamour, GQ and lots of others. We’re in China, Japan, Taiwan, India, Russia, Italy, France, Spain, Germany, the UK and Mexico.

Historically, we’ve had different tech stacks in markets all over the world. Now we’re looking at unifying our core platform, including our CMS and data infrastructure. This is a new international team, with a hub in London, that has the opportunity to help define our architecture, tooling, what we ship and how we ship it. You’ll get a rare look at digital publishing around the world.

Our stack is: Node, JS (ES6), React and AWS. Micro-services architecture. TDD. A strong background in utilising and creating REST APIs is desirable, as well as working with CMS tooling and platforms. Experience in delivering highly reliable, scalable and decoupled applications from back to front-end is a must.

Roles we’re hiring for:

* Software Engineers

* Senior Software Engineers

* Infrastructure and Automation Engineers

* Operations/Site Relaibility Engineers

* Data Analysts / Engineers

* Product Managers

Interview process:

Phone screen —> 1st stage interview —> 2nd stage / technical interview

Get in touch: SMR@condenastint.com

Sure, there are a bunch of places and ways you can do this.

For a start, companies of all shapes and sizes have or are building internal data technology teams. Almost any large company wants to do things with data that exceed what they can achieve by buying services. So they chuck all the data in a warehouse, and then find themselves in need of a way of interpreting and visualising it. You get fully-fledged internal facing products built on that premise all the time.

Alternatively, visualising data is a huge part of what modern media companies do. Examples range from Quartz, who built Atlas[0], amongst other things, to Bloomberg, whose business facing financial intelligence services have to make large volumes of data intelligible at a glance.

Beyond just the media, if you look at products like Facebook's Ad Platform or Google's DFP or Analytics, the UIs devote a ton of effort towards visualising data. It's probably harder to find tech companies that don't do large amounts of this than companies that do.

I haven't seen it as a consultancy role, but it is certainly something you could do on a contract basis with some companies if you wanted to. As with any software contracting, if you can show a great strength in a narrow niche you will command near-monopoly pricing for your services.

[0] http://atlas.qz.com/

We spent a lot of time talking about that balance. The thing to remember is that these conversations are happening in the context of an industry that's in structural decline. You have ever lower print revenues, and Facebook and Google taking 80%+ of the spend that's moving to digital. And then you have a sales culture incentivised on short-term outcomes. In that environment it becomes really hard to turn down a buck.

My two cents right now would be that consumer revenues (people paying you directly) is probably the only way to run a profitable generalist news company. That, or have the backing of a nation state (BBC) or philanthropic institution. If you want to run a business from ads on the internet, you need a great case for why you're a better option than Facebook, and most news companies just can't make that case.

At the Guardian we needed our own video player, because we couldn't rely on a third party platform not to take down something that we published. Editorial independence was important.

We implemented our player on top of video.js, and most of the developers who were there at the time still have nightmares about it.

We finally got the thing working, looking good, embeddable, reasonably cross-browser. We shipped it. A few days later, we get a curious email from some ad provider. "It looks like your VPAID ads have stopped running!"

Oops. We'd naively believed we could live without Flash (I take full responsibility for this stupidity). The sales folks pointed to a big gap between our old projected revenue and our new projected revenue. So we went and did the work[0], hating every minute of it.

The underinvestment in ad-tech by publishers and the cancerous ecosystem of vendors that have grown up around it is one of biggest collective mistakes made by an industry.

I am optimistic that this problem can be solved, and we are actively looking at this at my current employer. We sell direct, usually without a ton of intermediaries. Talk to me if you want to know more.

Incidentally, if you want to know if a publisher is going to survive the next five years, a decent proxy is the number of intermediaries involved in their ad supply chain.

[0] https://github.com/guardian/video-js-vpaid

The strategy of proxying real usage to a second code path is incredibly effective. For months before the relaunch of theguardian.com, we ran traffic to the old site against the new stack to understand how it could be expected to perform in the real world. Later of course we moved real users, as incrementally as we possibly could.

The hardest risk to mitigate is that users just won't like your new thing. But taking bugs and performance bottlenecks out of the picture ahead of time certainly ups your chances.

Centralisation of process isn't just about dollars for data. Yes, for the business model to work, the company has to gather a lot of data that it can look at all at once. But that's perfectly possible to do through a network of services, even services you don't own. See ad-servers.

Centralisation on the product level – that is, all activity happens on this particular piece of user facing software – is also a function of ease of use. If a thing is being accomplished by a distributed set of different interfaces, each with their own rules of the road, then there's significant pain for the end user in navigating all of that. In this way, good UX is naturally monopolistic.

Disclaimer: I briefly worked for Academia.edu a few years back.

Typically there'll be a CMS flag available to powerful users (editors). That's how it works at the Guardian.

It sets a boolean (shouldHideAdverts) in our content API[0], which we use in templates[1] to suppress commercial logic.

There are obvious business reasons for this. It's common for it not to be in the advertiser or reader's interest to show commercial messages against some content.

[0] http://content.guardianapis.com/world/live/2015/mar/24/germa...

[1] https://github.com/guardian/frontend/blob/4cb7e07c15a03568c2...

As the author was kind enough to pick us as an example, here's some background on what some of those requests are doing.

hits.theguardian.com points to our Omniture implementation, which is the main tracking suite used for macro-level reporting (like when we say we have X unique monthly browsers, or whatever). So if you want to be invisible to that, leave it blocked.

ophan.theguardian.com points to our own analytics tool, Ophan, which does things like tracks whether you "read" the article. It's for journalists to work out if people like their stuff. All the views of the data are aggregated, but if an analyst really wanted to they could go write some SQL to look at the behavior of individual cookies. So if you want to be invisible to that, leave it blocked. A quick Google [0] will turn up lots more about Ophan and how it works.

Our only calls out to Facebook and Twitter are to retrieve share counts for the current URL (besides articles with embedded tweets, for now). These are probably relatively safe to unblock, but if that information doesn't interest you they're equally safe to block.

api.nextgen.guardianapps.co.uk is handling most Guardian stuff that gets ajaxed onto the page, like suggestions for what to read next. It's pretty harmless and required for a bunch of functionality. All the guim stuff is obviously just static assets.

It would be cute if there was some way of us hinting to the plugin which domains were needed to not break the site, though likely impractical in the real world.

[0] https://www.google.co.uk/search?q=ophan%20guardian

Looks like that list hasn't been updated since our domain switch. If you really want to block our internal analytics (which are in practice fairly harmless) replace "hits.guardian.co.uk" with "hits.theguardian.com".

   "It seems to me then that the purpose of cerebration sessions 
    is not to think up new ideas but to educate the participants 
    in facts and fact-combinations, in theories and vagrant thoughts."
   

Thanks for the heads up - I'll get that fixed.

Indeed, it's evolved over time as I've needed more from it but the UX has wound up pretty awful. Adding a personal statement for example involves finding and pressing the oh-so-very-intuitive "add block" button at the bottom of the edit page.

For reference you can drag and drop any of the sections to reorder them, and most of the fields will happily accept Markdown.

Any feedback appreciated for next time I have a weekend spare :)

I made a similar thing a while back. My resume in PDF:

http://hackerb.io/cantlin.pdf

In MD:

http://hackerb.io/cantlin.md

In JSON:

http://hackerb.io/cantlin.json

You can generate a decent chunk of the content from LinkedIn/GitHub too :)

http://hackerb.io/

A good point, though not something we've heard repeated in UX sessions so far. For me the cinemagraphs ease the journey through the three thousand word piece, and help me orient myself in the text.

Actually, the difference seems specific to US English. My OED includes vise only as an alternative to vice, which carries both meanings. A quick Google also turns up this [1] article, which claims (without citation) that "In the U.S., the word for the clamping tool comprising two jaws closed and opened by a screw or lever is spelled vise. Outside American English, the vise spelling rarely appears. The gripping tool is instead spelled vice."

--

[1] http://grammarist.com/spelling/vice-vise/

I can't say for certain, but I don't think that's something we've split tested in isolation. We've found with typography testing that you need to commit to fairly long running tests to see anything statistically significant.

  > Can you go into a bit more detail for us about what the back-end which supports
  > this is like, what sort of entities you use in your CMS

  > what sort of techniques you use to separate out styles which are only used on
  > one page/section etc?

  > Are you just working on some stories for the Guardian team, or working full-time
  > on Guardian stuff?

--

[1] http://guardian.github.io/content-api-docs/index.html

[2] https://github.com/guardian/frontend

[3] http://gu.com/humans.txt

We've done much more impressive bespoke layouts than this in the past, but this one was made 100% with native CMS entities. AMA.

The blanket wildcard 301 redirect between .co.uk and .com was one of the quicker things to implement, since our path structure hasn't changed. These should cause pagerank to migrate fairly seamlessly. It's also no accident that the move was scheduled for late July, one of the slowest months for us in traffic terms, reducing risk. We saw Google referrer traffic take a nose dive yesterday, but appears to be recovering nicely today and is expected to return to pre-move levels over August.

I'm one of the product guys at The Guardian involved in this project. It was quite an undertaking. Happy to field any questions you might have as best I can.

I'd like it even more streamlined. Send five anonymized snippets to my inbox every Friday and let me click one button to order one of them to my door. Anyone know a service like this?

Sadly neither Mint nor Simple are available in the UK.

In London:

1. Include a one to two paragraph cover letter that you wrote specifically for the opening you're applying for. Make the quality of English very high. Use simple letter-style formatting, address in the top right, company logo in the top left if you have a freelance brand that you're using.

2. Include a two page CV. Simple formatting please (I am going to print it and write on it). Mine has worked well for me (though in retrospect is too wordy!), http://hackerb.io/cantlin.pdf, you can get one from http://hackerb.io.

3. Make both documents PDFs. Anything else is a pain for me.

4. Include links to your web presence, if you want. They can be in the cover letter, CV or email. You'll be Googled anyway so it's best to be proactive, especially if you have stuff on Github, SO, etc.

5. Companies vary, but be mindful of potentially needing to get your application through an HR department who at best will be searching for keywords from the job post.

6. Startups are a different game. Your CSS3 logo is a good stab (though make sure you back it up with meat). If I were looking for a startup role today I would be focused on making connections through events, social media and the open source projects they use.

London, UK. The Guardian. Software Engineer.

We're hiring :)

Come hack the news.

The Guardian are predominantly a Scala shop but use anything that does the job. We're into that whole agile thing, so expect a minimum of bureaucracy.

My team works on The Guardian's Content Platform, the central infrastructure that enables virtually everything we do here. The Content API holds a datastore of Guardian content from the 90's to the present day and serves about twenty million requests for it every day. It powers large chunks of our desktop site, as well as the entire mobile site, our Android/iPhone/iPad/Kindle apps, our syndication business and a heap of lucrative partnerships. We're also the ones best placed to be looking at non-traditional revenue streams – how do we generate value from our content except through our own ad-support properties?

We have hard problems to solve. We offer a competitive salary. And, it being The Guardian, health insurance and a good pension come as standard.

Ping cantlin at guardian.co.uk if you want to grab a coffee.

App Script is great for knocking together ad-hoc spreadsheets that pull in data from your company's HTTP APIs.

It's the best thing I've seen so far for giving non-technical colleagues visibility into whatever organisation data you have that's programatically available. They already understand spreadsheets, so there's no complexity to overcome when they come to play with them. It's trivial to base the output on a few user-defined cells, so you can put together fairly powerful features without ever having to build a user interface. You even get to do stuff with the logged in user's Google account. And since the toy apps seldom get too big, JS that you write in your browser is the perfect low-friction development environment.

Broadly speaking this is just what happened to us at The Guardian.

Our major takeaways have been a drive to 2FA-by-default for all users, and a move to managing social accounts through intermediaries like HootSuite.

Thanks for that - Rainforest look very interesting (what I can see of it). "QA as a service" sums it up nicely.

In some circumstances "accumulation of knowledge" in a tester is exactly what you're trying to avoid. Fresh eyes can be very valuable. Amongst other reasons, this is why we don't give developers sole responsibility for testing their own work.

We've needed a crowd-sourced human testing platform for software products for some time.

It would need granularity: as a developer I should be able to purchase N minutes of time from N people, potentially in such and such a demographic.

It would need an API: I should be able to build human testing into my deployment infrastructure.

It would need accountability: at minimum I want webcam footage of the tester using my product.

There are complications, but I see no reason why almost all of these couldn't be overcome by sufficiently smart automation.

Someone go build this!