9 things you need to know about the “Code in your browser” tool
ScraperWiki has always made it as easy as possible to code scripts to get data from web pages. Our new platform is no exception. The new browser-based coding environment is a tool like any other.
Here are 9 things you should know about it.
1. You can use any language you like. We recommended Python, as it is easy to read, and has particularly good libraries for doing data science.
2. You write your code using the powerful ACE editor. This has similar keystrokes and features to Window-based programmer’s editors. 
3. It’s easy to transfer a scraper from ScraperWiki Classic. Find your scraper, choose “View source”, then copy and paste the code into the new “Code in your browser” tool. You have to make sure you keep the new first line that says the language, e.g. “#!/usr/bin/env python”.
4. There are tutorials on Github, if you want to learn to scrape. It’s a wiki, please help improve them! The tutorials work just as well on your own laptop too. 
5. To run the code press the “Run” button, to stop it press the “Stop” button. 
6. The code carries on running in the background even if you leave the page. You can come back and see the output log, or even see a scheduled run happening mid-flow.
7. It has flexible scheduling. As well as hourly, daily and monthly, you can choose the time of day you want it to run.
8. You can SSH in, if you need to do something the tool doesn’t do. Your scraper is in “code/scraper”. You can install new libraries, add extra files, edit the crontab, access the SQLite database from the command line, use the Python debugger… Whatever you need.
9. It’s open source. You can report bugs and make improvements to the tool’s interface. Please send us pull requests! Want to know more? Try this quick start guide. Read the tool’s FAQ. Or find out 10 technical things you didn’t know about the new ScraperWiki.
Or there’s the even more powerful, less bloated and historically more stable CodeMirror editor [ http://codemirror.net/ ], an earlier version of which was the basis of Scraperwiki Classic.
Was there a recallable conscious rationale for the choice of Ace, or did it fall out of the mixture this way by default, gut-feeling, group-think, like so many technology choices generally do.
In this case, it doesn’t make any difference, because the two are pretty much equivalent at this stage. However, such decisions do warrant deeper introspective retrospection to discover what was it that won out in favour of the one you didn’t use that couldn’t even get its brand straight. What exactly did they do to earn your trust, and can you get it in smokable form?
BTW your links to Scraperwiki Classic are broken. This doesn’t exist: http://classic.scraperwiki.bat/
Hi Julian!
I originally made the “Code in the Browser” tool in my spare time, and I picked ACE because it seemed the dominant, best made and best supported Javascript code editor in 2013.
If there’s good reasons you don’t like it, you can fork the tool and change it to a different editor. Is there some particular thing you dislike about ACE?
Finally, yes, technology choices should often be made for social reasons. There’s no clear separation between the people and communities who make and maintain and know a technology, and it’s technical lines of code and features and usability.
For example, usable only means usable within the heads of its users, who already know certain things before they start. And code is no good if it isn’t improved and maintained.
Obviously, products can do new things, and train their users, and lead. However, generally amongst geeks too much attention is paid to that as if it is the only thing. In practice, as you know within Autodesk, people’s behaviours and organisational structures, are often more dominant in terms of delivering actual benefit to the world.
You have to hack those things too.