cantlin
Joined 15 years ago
Karma
559
Submissions
96
Member since
May 3
http://cantl.in
View on Hacker NewsRecent submissions
Comment · 5 years ago
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.
Comment · 10 years ago
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: [email protected]
Comment · 10 years ago
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.
Comment · 10 years ago
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.
Comment · 10 years ago
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.
Comment · 11 years ago
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.
Comment · 11 years ago
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.
Comment · 11 years ago
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...
Comment · 11 years ago
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.