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…
Our web development workflow is completely broken
41–50 of 121 posts
Re: Our web development workflow is completely broken
#42I am getting "Application error" when trying to view this post, which proves the point, I guess.
Re: Our web development workflow is completely broken
#43I don't want to defend Firebug, but in my experience the Developer Tools are a pain to use in comparison to Firebug. (e.g. autocompletion of css properties and property values only works with tab and not also with return, it takes too many clicks to see the metrics,....).
What's the features that make the Developer Tools better in your experience?
Re: Our web development workflow is completely broken
#44I am getting "Application error" when trying to view this post, which proves the point, I guess.
Also, javascript must be enabled prior to the application error even appearing.
It's a bunch of static text, for goodness sake.
Re: Our web development workflow is completely broken
#45A small nitpick: the article lists the "IE Developer Toolbar" for IE6 first, and suggests that everybody else's development tools followed that model. In fact, the earliest reference I can find to the IE Developer Toolbar suggests[1] that it was released in early 2007, while the Firebug version history[2] shows Firebug v0.2 released in January 2006, so it's about a year older than IE's developer tools. Even if Firebu…
Yes, before Firebug, we were using MS Script Debugger/Script Editor in IE. It wasn't great, but it was more reliable for script debugging than Firebug for a long time.
And IE development could use Visual Studio (and later Visual Studio Express web edition) for a slightly better experience than the MS Script Debugger, although the core issues such as not being able to see let alone debug toplevel javascript remained).
[0] https://developer.mozilla.org/en-US/docs/Venkman_Introductio...
Re: Our web development workflow is completely broken
#46Re: Our web development workflow is completely broken
#47This 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…
Re: Our web development workflow is completely broken
#48Earlier quoted context omitted.
Yes, because the introduction of the computer was a minor change to the world that only a pedant would have bothered with?
Good point, it wasn't a minor change. I meant to specify working computers.
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, like when an article mixes up the order in which two pieces of software were released.
Re: Our web development workflow is completely broken
#49In ipython I use autoreload (thanks to a tip on HN) so that the code in the objects in memory is kept in sync with my editor. My workflow is: load up a bunch of objects I'm working on, try to get the expected output, fail, change code in my editor again, check the the output, repeat. Within ipython you can even '%ed obj.broken_function' to edit it directly in vim. There's no doubt that the auto reload discovery improved my efficiency. Aside from the time it saves, I'm able to think of my running code and on disk code as the same thing. Don't underestimate how powerful that is.
But as I said, my code is now mostly frontend code. After over 15 years in web development the reload cycle has become second nature to me. It's silly though. I have a lot of state to maintain in the js and every reload is expensive. In my specific case I could be looking at 2 minutes to even load the objects from the web server.
I'm going to have a look at the chrome options to see what's available in terms of hot code swapping. I disagree that it's important for all browsers to support it. Even just finding a good solution in the browser I do most development in (chrome, presently) would be a major win.
Re: Our web development workflow is completely broken
#50Shameless 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