Live data from Hacker News

Building a Text Editor for a Digital-First Newsroom

open.nytimes.com

131–140 of 176 posts

Re: Building a Text Editor for a Digital-First Newsroom

#131
post #40
post #36

I'd love to work for this engineering team. Their tech blog and github is full of interesting projects.

the BBC sounds like it has a really good tech team too. wonder what it is about newspapers that leads to this sort of tech culture.

Come hell or high water, the paper has to be on the newsstands the next morning. It is the very definition of mission-critical computing.

I worked on the Graun’s website/publishing backend in the late 90’s. Lots of Tcl/Tk.

Re: Building a Text Editor for a Digital-First Newsroom

#132
So, we had this product (or the larger one anyway) demoed for my work and our takeaway was that only really large organisations could possibly use it. It needs to many human hands between writing an article and getting it published. We want to move to something more automated, and this system would have been a serious setback.

Re: Building a Text Editor for a Digital-First Newsroom

#133

Earlier quoted context omitted.

Not all languages are created equal. While yes a developer with years of experience in python may have lots of transferable skills to other languages, my team arent going to hire someone for a mid level/senior position without a good knowledge of c++

C++ is somewhat of an outlier due to the sheer size of the spec(and getting bigger all the time). Not everyone will use the same subset of features either, which complicates things. That said, aren't you using C++ as a proxy for other needed skills though? Many Python programmers are not exposed to concepts like vtables, or they do not know how a linker works(or why it is even needed). Heck, many won't have done manu…

Even though most people won’t use everything, all c++ programmers will need to understand RAII, manual memory management, lifetimes, effects of inheritance and some* undefined behaviour. We’d probably take people with C experience, and maybe Some D or Rust, but really for a mid level C++ job we wouldn’t accept much less than C.

Funny that you mention linkers, as they’re a bit of a minefield. Lots of the behaviour of linkers is platform (and implementation) dependent, I.e. are you building a shared library or an exe on windows or linux, and there are different gotchas for all of them. We wouldn’t expect people to know al of those things, but it definitely helps when it comes up, and you don’t have the same problem (ODR violations come to mibd) in many other languages...

Re: Building a Text Editor for a Digital-First Newsroom

#134
post #111

Cool, but it's yet another case of re-engineering the same thing. (edit: its not entirely new). Splitting editors into an abstracted structure for finer control over data and presentation is something that's been done for a decade now in various text editors. Medium and Basecamp started similar projects and there's Mobiledoc which is trying to standardize the format. It'd be nice if all this effort focused on a singl…

Going with your own format has some advantages, but using a well known popular format also has advantages. I did look into ProseMirrors and other editors but due to the formatting I ended up making my own. Where I've gone the painful route of having HTML nodes instead of a JSON tree. My reasoning is that I always want to end up with HTML anyway, and this also allows switching back and forth between editing HTML and W…

If you're looking for a traditional editor then Froala is worth every penny. It has 10x the features of all these more modern versions and still outputs solid HTML.

Re: Building a Text Editor for a Digital-First Newsroom

#135

This isn't even a test editor. It's closer to a web publishing tool. The article also didn't talk about the normal text editor challenges like the way the text is stored in memory and modified.

You sure this is only for web? I got the impression that a story authored with Oak could just as easily be vectored to the web, newsprint, or magazine. Clearly video and audio content don't apply to the latter two but I can see where Oak-authored content is sucked into the print layout app(s) and more metadata (fonts? formatting?) applied that are only relevant for the dead-tree versions.

Re: Building a Text Editor for a Digital-First Newsroom

#136

Earlier quoted context omitted.

In most hiring settings this isn't true though. Language-specific skills actually do matter, for all but entry-level positions at massive tech companies. It's not like my 3 years of experience in Ruby is immediately translatable to Java/Python/whatever. Could I get up to speed in those languages in due time? Sure. But if you were on a hiring committee, hiring for a team that works mostly with Java (or whatever) would…

Language-specific skills actually do matter, for all but entry-level positions at massive tech companies. Absolutely, which is why I didn't stop at "I am a developer". That "who is good at Python" bit is definitely important. However , seeing yourself as a "Python developer" rather than "a developer who is good at Python" makes it look like you see every problem as something you'll solve using Python. That's bad. Tha…

>However, seeing yourself as a "Python developer" rather than "a developer who is good at Python" makes it look like you see every problem as something you'll solve using Python. That's bad.

If a company didn't hire me because they idiotically interpreted "I am a python developer" to mean "I would try to build a rendering engine in python" then I'd say that's probably a bullet dodged.

I'd interpret it as "I don't build rendering engines but I build other stuff for which python is a good fit", but maybe that's just me being weird.

The trope about great programmers being people who reverse binary trees in their sleep and being able to swap ecosystems at the drop of a hat needs to die. Great programmers specialise.

Re: Building a Text Editor for a Digital-First Newsroom

#137
post #87

Earlier quoted context omitted.

I suspect that NYT will contribute quite a bit back to ProseMirror out of enlightened self-interest but not give away the secret sauce that make Oak a competitive advantage for them. This is REAL freedom in software: without the ability to build a closed-source, for-profit business it won't succeed. I'll take MIT/BSD/Apache over something with a herpes license (GPL/AGPL) any day.

Can we leave the Slashdot-quality trolling about licensing back in the previous millennium where it belongs? There are, of course, successful projects licensed under the GPL and AGPL (Linux comes to mind), many of which have for-profit businesses; there are plenty of people with different priorities about what "REAL freedom" is. And calling the licenses that match their priorities "herpes licenses" is unlikely to con…

Trolling aside, the freedom allowed to not show all of your cards that MIT/MSD/Apache allows is better for business, and if the app is essential to their business then they will contribute fixes back upstream. An example is Juniper and their myriad contributions to FreeBSD. This allows Juniper to pull down upstream updates without it being a complete goat-rope to integrate with their own secret sauce code; if Juniper were using Linux instead of FreeBSD then anyone could demand full source code and sell knock-off solutions based on Juniper's work and the result would be less actual development of the technology (for lack of profit motive).

Re: Building a Text Editor for a Digital-First Newsroom

#138

Earlier quoted context omitted.

In most hiring settings this isn't true though. Language-specific skills actually do matter, for all but entry-level positions at massive tech companies. It's not like my 3 years of experience in Ruby is immediately translatable to Java/Python/whatever. Could I get up to speed in those languages in due time? Sure. But if you were on a hiring committee, hiring for a team that works mostly with Java (or whatever) would…

> It's not like my 3 years of experience in Ruby is immediately translatable to Java/Python/whatever. It should be. Picking up language X is very easy for most values of X (more esoteric ones excluded). After you know a few (and the more diverse the set, the less new concepts you'll see), picking up a new one is quick. If it is something like Go, it's a weekend's worth. Using the language in idiomatic ways and knowin…

>Using the language in idiomatic ways and knowing the most useful libraries and frameworks does take more significant ramp-up time.

Yeah. As in years. This stuff also changes all the time so requires perpetual learning.

>But languages? It's a mere tool, and you need more than one in your toolbox.

It's not a mere tool and languages are more than just trivially learned syntax. They are the umbrella under which a panoply of tools, approaches, ideas, priorities and culture aggregate.

Sure, you specialization isn't necessarily always the optimal approach and sure there are benefits to the cross fertilization of ideas across community lines. However, being a jack of all programming languages, master of none probably means you'll suck more than a specialist at a lot of stuff.

Moreover, some ecosystems plain suck and avoidance is the sign of a good programmer. Statistically, you're probably a worse programmer if you've used a lot of PHP and better if you've learned rust/F#.

Re: Building a Text Editor for a Digital-First Newsroom

#139
post #96

I'm choosing an editor for my project right now. Can someone compare ProseMirror to Slate and Quill? What is the difference, which one is better? What do I need to know to choose one?

I've used a lot of quill in the past couple of years. It has some tricky bits, but seems similar in a lot of ways to ProseMirror - separate internal representation of data that gets rendered into HTML, delta-based state changes, etc. At this point, I use quill out of momentum - it was the only game in town when I started working with rich text, and now I know how it works. I also like it enough that I've never felt the need to go find something else; it's always done what I want.

I think to fully experience all three of those editors, you should build the following: something that generates a rich text input using the editor, updates a data store (can be just in-memory if you want), and then re-presents the rich text in a read-only format.

With Quill in particular, there's two ways to approach the second part - you could dump the data into another instance of the quill editor, but one flagged as read-only, and let quill handle rendering out all the elements. I don't do that, myself, as it's a bit heavy and relies on the DOM to be present to create the end result (meaning rendering rich text into emails on the server side can be tricky). Instead I use a library (that I wrote) that converts the quill representation into an HTML string that can be later injected into whatever place it needs to go.

In general, I think that's where the one of the important pain points is for any major modern text editor exist - converting the internal data representation into a canonicalized HTML string. This gets further complicated by your framework - it's easy enough to inject an HTML string, and angular 1 lets you even compile that so you can have custom elements there, but angular 2 has no such facility (compiling; you can still inject). So rendering custom elements into angular 2 is feasible but quite tricky.

You'll need to figure out how to handle custom elements too, like at-mentions and so on; those are really domain-specific. How I handle at-mentions in quill (with a pop-up autocomplete) depends on the structure of the overall system as well as the framework I'm in - angular 1, 2 and react all suggest different approaches for this.

Anyway, this is all a long response that means "it depends". Each editor has its own strengths and weaknesses that are exposed by the specific data and presentation needs of your project and the other frameworks in play. But building an atmention or other custom element and converting from the internal data structure to HTML is a good test of functions for all of those.

Re: Building a Text Editor for a Digital-First Newsroom

#140

Earlier quoted context omitted.

A word of unsolicited advice: Someone who thinks "I am a Python developer" is generally less useful to a team than someone who thinks "I am a developer who is good at Python."

Not all languages are created equal. While yes a developer with years of experience in python may have lots of transferable skills to other languages, my team arent going to hire someone for a mid level/senior position without a good knowledge of c++

May I ask, what's the company (and the particular team)?
Post reply on HN