jpallen

ShareLaTeX - UK, full-time, remote, first non-founder developer.

Help us empower scientists by building usable research tools.

We’re looking for a full stack web developer to join us as employee number 1 at ShareLaTeX (www.sharelatex.com). Our flagship product is an online LaTeX editor that makes it trivial to get started with LaTeX and collaborate with your colleagues. Students and scientists love us, and now we’re looking to expand our team so that we can solve similar workflow problems in data analysis and numerical modelling (using Python and R).

You should be comfortable quickly learning new technologies and enthusiastic about improving the efficiency of scientists and their tools. Our current technology stack involves Node.js, MongoDB, Redis, Coffeescript, Angular.js, and Docker, so experience in these is useful but not required. We’d rather see that you have demonstrable interest in the problems we are solving, and that you’ve created some great stuff in the past.

Some reasons you'd enjoy working for us:

* Around 80% of our codebase is open-source and we’re big fans of free software.

* We’re agile (with a lower case a). We test everything (unit and acceptance), we have a CI build process, a full staging environment to play with, and we automate as much as possible.

* We don’t expect you to have to fill up a 9-5, 40 hour work week. A work/life balance is important and we don’t think programming is an activity that can be neatly time boxed.

* You can work fully remotely (in fact, you probably will). The founders work remotely already.

* We’re a bootstrapped company with no outside investors.

Send me an email: james@sharelatex.com

ShareLaTeX - UK, full-time, remote, first non-founder developer.

Help us empower scientists by building usable research tools.

We’re looking for a full stack web developer to join us as employee number 1 at ShareLaTeX (www.sharelatex.com). Our flagship product is an online LaTeX editor that makes it trivial to get started with LaTeX and collaborate with your colleagues. Students and scientists love us, and now we’re looking to expand our team so that we can solve similar workflow problems in data analysis and numerical modelling (using Python and R).

You should be comfortable quickly learning new technologies and enthusiastic about improving the efficiency of scientists and their tools. Our current technology stack involves Node.js, MongoDB, Redis, Coffeescript, Angular.js, and Docker, so experience in these is useful but not required. We’d rather see that you have demonstrable interest in the problems we are solving, and that you’ve created some great stuff in the past.

Some reasons you'd enjoy working for us:

* Around 80% of our codebase is open-source and we’re big fans of free software.

* We’re agile (with a lower case a). We test everything (unit and acceptance), we have a CI build process, a full staging environment to play with, and we automate as much as possible.

* We don’t expect you to have to fill up a 9-5, 40 hour work week. A work/life balance is important and we don’t think programming is an activity that can be neatly time boxed.

* You can work fully remotely (in fact, you probably will). The founders work remotely already.

* We’re a bootstrapped company with no outside investors.

Send me an email: james@sharelatex.com

This is great, thanks! Quick question: Is there a best practice for handling rate limiting? I.e. if you send us X number of web hook updates in quick succession for a user, are we ok just sending X delta requests back at you in quick succession? Or do we need to worry about rate limiting? What's the maximum rate we can expect to be sent web hook requests for one user?

ShareLaTeX - https://github.com/sharelatex/sharelatex is a web-based real-time collaborative LaTeX editor.

The stack is a walking cliché: Node.js, Redis, MongoDB, Coffeescript. Lots of open issues, with plenty that are tagged 'good for beginners' (to the project, not necessarily with the tech). We've also got a dev chat room where we're available to help you get started whenever we're online: http://www.hipchat.com/g1nJMcj7b

We have strong opinions about the correct way to write javascript/coffeescript to be unit testable, and how to write apps based on lots of small services which are robust and testable. We'd be delighted to have people contribute and either sway our opinions, or pick up some of our experience.

Our history system isn't great at the moment. We made the classic mistake of building a feature that doesn't really work for a lot of people. However, we understand want people want a lot better now and we're working on something that is very inspired/copied from the change tracking in Word. It's a very popular request!

You can split your document into multiple files on ShareLaTeX too, just like you could on your own computer with LaTeX. There is still a lot that we'd like to add into our IDE, but providing an experience that compares with offline editing is an important priority for us.

I've put this on our template todo list, thanks!

We'd love to hear any things you think we could improve. And of course a pull request would be amazing as well!

We'd love to start pushing forward on some reference manager integrations, so a pull request would be amazing! It might be best to have a quick chat about how to implement this. My email should be in my profile.

Thank you for your support! There is a danger of sounding like a broken record, but when it comes to Dropbox sync: We're working on it, I promise! :) Dropbox recently released a new API end point that allows for long polling which should allow us to do instant synchronisation both ways. It's on our todo list!

Phew, lots of questions :). I've only really done this once (with ShareLaTeX), and it feels like a constant challenge in many ways. I think I'd have to try it a few more times with other products to understand which challenges are the important ones. So no big insight there, sorry.

I'd definitely recommend trying to start a business with monthly recurring revenue. It makes things quite stable and predictable, and watching it grow is like crack.

We're not that worried about this impacting our revenue. Most of our value that people pay for comes from being a hosted service.

You're not the first (and I doubt you'll be the last) to think that we're some sort of social media site based around prophylactics :)

We don't have any hard data - this is based on our personal vision, and our understanding of our user base. People mostly use ShareLaTeX because: 1) There is no installation, 2) You can access it anywhere, 3) You can collaborate easily and effectively without needing to be technical and know git/svn/etc. I don't think being open source will threaten any of those points, but it will make ShareLaTeX accessible to the large group of people who want to run a local version but haven't been able to so far.

It will be interesting to see how things look in a months time. I'll try to post an update!

There isn't a perfect way that I'm aware of. In LaTeX, the commands end up translating to direct formatting commands that only make sense in a fixed layout document, so HTML conversion will be an approximation at best. I think Pandoc (http://johnmacfarlane.net/pandoc/) does a reasonable job though.

Basically, we wanted to! We've benefited hugely from open source projects ourselves, and have always enjoyed being part of the community surrounding them. It seems like the default state is to not be open source, but we realised that since we own and run the business behind ShareLaTeX, we had the freedom to play by our own rules. We also think it makes sense from a business point of view as well, since it will (hopefully) make us accessible to a wider audience, particularly onsite installations that we don't have the resources to support as a proprietary 'enterprise' system.

We've written a bit more about our motivations in our blog here as well: https://www.sharelatex.com/blog/2014/02/21/sharelatex-is-now...

James from ShareLaTeX here. I'm hanging around all day today ready for the barrage of pull requests that we're about to receive(!) so feel free to ask me any questions.

We're using docker at ShareLaTeX to run the latex compilation. It lets us have lightweight isolated containers so that we can now let people do scary/cool things like run R code in a secure way.

What are you guys doing that will give us a compelling reason to switch from Hootsuite?

Our team is only a handful of people but we've found Hootsuite really useful for making sure everyone has access to the same feeds and being able to see what we're all doing without stepping on each others' toes. It's also great that it lets us have one unified overview of all of our social networks (although its support for Facebook and G+ is nowhere near as good as for Twitter). If you guys can nail these two things, but actually make G+ and FB feel like they aren't just afterthoughts then we'd definitely be willing to give it a go!

I don't necessarily disagree with you, I just always prefer to sit more on the side of 'don't reinvent the wheel if you don't have to'. I don't think creating an n-th competing format is the answer here.

In the examples in your final paragraph, surely what is needed there is a new tool, not a new data format?

I think the larger 'problem' (if it really is a problem, and not just hackers wanting to believe they know the One True Way) is that there is no such thing as the typical 'scientist'. Every small sub-discipline has its own needs, its own standards that it has settled on and its own toolchain. There is definitely room for improvement within every one of these small areas, but there's no global problem that needs solving.

I don't really know why human readable is important here, but there already exist open data formats that have good support for the things that matter: large data sets, compression and support for multiple platforms and languages. I'm not very knowledgeable about any, but some I am aware of:

http://www.unidata.ucar.edu/software/netcdf/ http://cdf.gsfc.nasa.gov/

I know Linode has been getting hammered for not being trustable or that they don't respond well when contacted, but in my experience they have been extremely responsive to any issues I have raised. I don't just mean technical issues either, we had what looked like a security breach on our account and it kicked of a small frenzy in their support staff and supervisory team to track down the problem. They figured out what had happened after a thorough investigation, gave us a full post mortem and promised they were reviewing procedures to make sure it couldn't happen again.

I've been maintaining an open source LaTeX web API called the CLSI (https://github.com/scribtex/clsi) for a few years now. This powers ShareLaTeX and ScribTeX, and I'm really keen for others to use it, and for the standard to evolve with more focus than just what I decide to add on a whim! As far as I'm aware, it's the only documented API for calling an online LaTeX compiler, and the design of the API is meant to be separate from the backend, so that the other online services could also expose a compatible API. If you're interested in perusing some sort of integration for LyX, then we need to talk further! My email address is in my profile.

Can you give an example of a piece of math notation that you think could be improved?

Maths is more like a human language - the writing necessarily does not contain a complete picture, just like a book can never unambiguously describe a scene. This is what sets it apart from the computer programs you have compared it with since a computer program is a complete, unambiguous definition of the thing it is describing.

All that math notation does is give us a language that sits somewhere between description and precision to let us talk about concepts that are very hard to formulate in natural language.

If it was made completely precise too much would be lost. Context is everything, and sometimes that requires you to understand the previous work in the field. I don't see a way around that.

Feeling like I'm part of something bigger than me and my own personal code. I won't try to rationalise it, because it's pretty much an emotional response, but I enjoy the feeling of other people using my code, because it means I've had a positive influence on the world.

I'm curious how you handle the LaTeX compilation, since in my experience this is one of the trickiest things to get set up securely. I created the "Common LaTeX Service Interface (CLSI)" (https://github.com/scribtex/clsi) as an open standard and open source HTTP API to provide access to a LaTeX compiler. I think it's one of these problems that people will keep solving again and again unless we work together to get it right. The CLSI currently powers ShareLaTeX, ScribTeX, and LaTeXLab (with a different implementation of a similar standard), so it's been well battle tested. If you'd be interested in integrating the CLSI with FlyLaTeX, I'd be more than happy to help out. Contact details are in my profile.

Thanks. I didn't invent the telnet REPL trick, but I've forgotten where I found it so I can't give credit where it's due, sorry.

Could you allow the requester to provide a link to the pay wall where they get stuck? People who have access to the paper through a university subscription could then easily click on that link and then immediately be taken to the paper. I imagine most people looking for a paper will already have come across this paywall and so will know where to find it. It would significantly reduce the overhead of the person fulfilling the request, but may be against the spirit of the site.

In many cases that I have come across, the DOI can be turned into a link that takes you to the article. Perhaps that would be enough.

Yes, we'd love to do that. I coded up a prototype a while ago and found that latexdiff can quite easily get confused and produce LaTeX code that won't compile. I definitely plan to revisit this though and try to get something working.

Yes, we have a feature called 'History' which you can access from the editor. It lets you see the changes that have been made to your project over time. It's a bit of minimum-viable-feature at the moment, but it's still quite useful, and we're always open to feedback on how to improve it for your needs.

I'm one of the co-founders of ShareLaTeX, and there are two main reasons that we've found that people really like ShareLaTeX. The first has been mentioned - you don't need to set up a LaTeX repository yourself. Even more than that, you can work on LaTeX documents from anywhere. It tends to be hard to find LaTeX installed on a computer if you're on the move and not using your own machine.

The other advantage is the ease of collaboration. While there are plenty of people in the LaTeX world who know git, there are plenty that don't as well. ShareLaTeX gives everyone a point and click way to make sure they are in sync with their collaborators. That said, we're getting quite close to offering git access to the projects for people who want it.

Also, my apologies that we keep appearing on the front page (along with a few other similar sites). We're flattered that people keep submitting us though.