61–70 of 121 posts
Shameless plug: I've written a small VIM plugin [1] that permits a workflow similar to what the author suggests. [1]: https://github.com/Bogdanp/browser-connect.vim
Would it be possible for you to add the source code of the play application (server) to your github ?
Thank you for your plugin :)
Shameless plug: I've written a small VIM plugin [1] that permits a workflow similar to what the author suggests. [1]: https://github.com/Bogdanp/browser-connect.vim
Nice one ! Would it be possible for you to add the source code of the play application (server) to your github ? Thank you for your plugin :)
Earlier quoted context omitted.
Good point, it wasn't a minor change. I meant to specify working computers.
That doesn't seem relevant. If it wasn't for hunter-gatherers, we wouldn't have much of anything; but that doesn't mean hunter-gatherers have much to contribute to particle physics. There are times when it's important to be pedantic, like when you're writing software. (I don't think we normally use the word "pedantic" in these cases, but I'm not going to argue the matter.) And there are times when it's not important,…
JetBrains webstorm looks really cool, I wish they'd push that functionality into PyCharm.
"The remote debugging protocols are incompatible with each other, and each has a different features."
[1]http://people.apache.org/~pmuellr/weinre/docs/latest/
With weinre you start a node.js debug server and add one script tag in your html. Then you start the debug client in a webkit compatible browser and finally the browser with the page you are debugging (it can be anything: mobile, remote or not).
weinre strongest points are:
- "weinre supports remote interaction, so you can run the debugger user interface on one machine and can debug a web page running on another machine. For instance, debug a web page displayed on your phone from your laptop."
- "weinre does not make use of any native code in the browser, it's all plain old boring JavaScript."
- "Because weinre doesn't use native code, the debug target code will run on browsers without specialized debug support."
Also try Live Reload[2], mentioned in the article, for a nicer editor+your_tool+browser integration.
- "LiveReload monitors changes in the file system. As soon as you save a file, it is preprocessed as needed (SASS, LESS, Stylus, Coffescript and others), and the browser is refreshed." (You don't hit reload, it uses a browser extension or a script tag)
- "LiveReload can invoke a Terminal command after processing changes. Run a Rake/Cake task, a Shell script or anything else you need."
This is one of the problems that TDD tries to solve. To make changes to a small piece of code, you don't want to have to go through a huge iteration of running up your server, going to your browser, moving around the app to get into the required state and then trying out the bit of functionality. No, you just write a test for that bit of code and run it. No browser needed. The cycle he describes is what you do at the…
I thought the problem he was trying to solve was to speed up simple things like text color changes or pushing elements around a few pixels. TDD doesn't try and solve that does it?
JetBrains webstorm looks really cool, I wish they'd push that functionality into PyCharm.
On one hand, the whole web stack is completely broken and insane. On the other hand, if you use the right development methodologies such as unit testing, MVC, MVP, MVVM, and/or frameworks that translate statically typed or functional code to JS, the write-build-run-debug cycle is not an issue, because in general it only becomes an issue with a wrong approach to programming. This is totally the same as in non-web-prog…
Yeah, I also think there should be a more fundamental discussion about where the web is heading. Instead of fixing the tools perhaps one should think about a new foundation for everything. Not sure HTML etc. is it.
And HTML trundled along unwanted in WHATWG through those times, scorned, rejected as inadequate and not suitable. And yet, XHTML2 got closed down, everyone switched back to the HTML path.
And processes involving changing web development from an environment to an output format - Google's GWT and Dart, don't seem to have gained much traction.
I don't know what happened to Xanadu, either.
You probably should dig into the history of Rich Internet Applications (formerly XUL, before Mozilla decided to stamp out the naming confusion with their own XML vocabulary), in the days before Ajax really stabilised and things drifted back into the browser.