[web] Your web development

I primarily use Homesite 5 for ASP development. Our backend database is SQL Server 2000. In regards to porting to ASP.NET, however.. I have no interest in porting these forums to .NET. Since Windows 2003 was released a number of improvements in "Classic" ASP have taken place.. the biggest of which involves script "template" caching. IIS 6.0 compiles ASP code and stores the compiled versions for re-use as needed. This limits most of the negative performance impact you normally associate with scripted languages.

So for me, there is no real reason to attempt to convert the 18 zillion lines of forum code to .NET.

---
Michael Tanczos

Hmm.

Servers tend to be mixed. IIS4/5/6 & FileMaker Web Companion.

I develop in:

ASP3 (mostly)
ASP.Net (getting more)
MS SQL 2000
MS Access 2000 (For small client hosted DB's)
XHTML/CSS2
XML4 Parser sp2

I tend to use DreamWeaver MX and Allaire Homesite 4.5 (Better than Macromedia Homesite 5.1, they chopped bits from it).
Bradsoft Topstyle Lite 3.5 for CSS (I keep meaning to buy pro)
WebMatrix for ASP.Net (Moving to V.Studio soon as I use .Net more)

And Notepad, its amazing how often I use notepad for quick amendments (and occasionly entire new sections of sites).

A lot of new stuff is being done in ASP.Net but I still spend time maintaining legacy apps that use ASP3 and will for a few years yet (If I stay of course).

Everything has/is being ported to XHTML (maybe 95% by now).

Jay

Notepad.

I use php with apache(latest) server, and mysql(latest) and i use dreamweaver for developing. I run my own server, but all my stuff is really put on to crxgames.com becasue its faster and more reliable.

I have a lot of projects - many are constrained technologically either by legacy decisions or customers preference.

In any case, our own stuff uses PHP/MySQL - mostly motivated by cheap servers.

PHP/MySQL - Advantage: Free, good performance for simple stuff, robust. Disadvantage: Poor international language support (character sets), limited tools, bad for programming in the large

Java/JSP: Advantage: good for programming in the large, good performance on complex / tricky stuff, excellent character set / unicode awareness, good tools. Disadvantage: Much bigger fixed overheads on server, typically slower deployment times.

MS/ASP: Advantage: little/none; legacy systems use it. Possible legacy integration advantage. Disadvantage: Everything; deprecated by developer, encourages bad practice and typically lousy for programming in the large; adequate performance in most cases.

MS/ASP.NET: Advantage: now properly supported; good APIs generally (with a few exceptions); proper unicode support (Like Java); generally easy deployment (depending on structure of course). Good for programming in the large. Disadvantage: Some tools problems with VS.NET; HTML bloat tendency; poor implementation of some web controls enforces artifical browser restrictions on apps, and limits usefulness if targetting old / small devices.

---

Mark

Professionally, I've used:

Access/ASP3/Personal Web Server, testing only
Access/ASP 3/IIS, live (yes, I know, but the multimillion pound multinational corporation asked for this)
MS SQL Server/ASP 3/IIS, live
MySQL 4/PHP/Apache 1, live

On my personal project here at home:
Apache 2 + mod_python + MySQL 4

Academically I also used:
Access/ASP3/IIS with JScript rather than VBScript... which was 'fun'.


Generally I/we've generated HTML 4 transitional, with CSS1.

However, my current home project is going to be XHTML. I tend to use whichever standard-compliant features I need, providing they work as intended in Firefox and Opera. Back in my professional web development days, when working for the people who used ASP, we didn't follow any standards, didn't write doctypes, and only tested on IE 5. I didn't get much choice in this.

I've very little interest in the hell that is XML and XSLT although I will probably do a little more work with it just for the sake of improving my employability. I never saw all that much benefit in adding that extra abstraction layer.

mod_python is awkward to start off with but once you get a decent dispatch and template system working, it's a dream to use and runs at approximately the same speed as PHP but without the line noise. ;)

These days I tend to rely on a text editor like EditPlus for my sites. It's easier to hit Ctrl-Tab, enter a CSS rule into main.css, Ctrl-S to save, Alt-Tab to the browser, and F5 to refresh, than it is to open up the various Dreamweaver windows, find the specific box for the attribute I want, edit it, close all the windows, and hope the screen's refreshed. Dreamweaver was great for me a few years ago but now it feels like a load of dialog boxes that come between me and the code.

Finally, I couldn't live without Mozilla Firefox's extensions. The DOM inspector shows you exactly why your CSS isn't working, and the EditCSS feature of the WebDeveloper extension lets you experiment with your CSS rules in real time. It also contains links to validate your page, shows images lacking ALT attributes, lets me quickly resize to 800x600 to see how it'll look in a lower resolution, etc.

[Edited by - Kylotan on July 1, 2004 7:08:25 AM]

I refuse to conform to the braindead callback model of most web frameworks. It's unnecessarily convoluted. The only things that keep it alive are inexpressive languages.

I want to program the web just as I program a terminal. Poor web frameworks don't let me. They force upon me the complexities of multiplexing between several clients. This is an example of bad factoring. The plurality of dialogues should be abstracted away.

This program -- a dialogue programmed for a terminal -- is extremely obvious:

puts("Hello, " + gets())

Yet in conventional web frameworks, I cannot write this:

puts("Hello, " + gets() + "")

This is because conventional languages are incapable of abstracting away the inherent eventual nature of web servers.

The web server main loop looks something like this:

while event = read_event_from_network() do  callback.call(event)end

The callback is bluntly called for all incoming events. This is inconvenient, since it forces the callback writer to manually separate clients from one another. That's done by passing around a session ID. So let's improve the main loop.

while event = read_event_from_network() do  callbacks[event.session_id].call(event)end

Now each callback can have its own state, and that state will affect only the client to which the callback is assigned. This, too, is inconvenient, since it still forces the callback to keep a lot of state that could be managed for him automatically. For example, a callback might look like this:

class MyCallback  def call (event)    if state == 'start' then      state = 'got_input'      event.respond_input_field    elsif state == 'got_input' then      state = 'start'      event.respond_text("Hello, " + event.text)    end  endend

That's a trivial state machine, and we're all quite used to them. But why do we have to codify it like that? We didn't have to write the terminal program like that.

Yet the problems are identical. The terminal gets() function doesn't sit in a polling loop. No, when you call it, it halts your entire program, and eventually it is resumed by an event handling loop in the kernel. When it is halted, its entire set of registers -- most importantly, the pointer to the stack and the code pointer -- is saved by the kernel; when a matching event arrives, the registers are put back in place, and the processor jumps to right after the gets call.

The same model can be applied to web programming. The only difficulty is saving the registers. You can't program that straight-forwardly in C, because the C language doesn't expose the registers to the programmer. Additionally, since the web server will be running all in one process space, not only the stack pointer will have to be saved -- but the entire stack. You can't program it straight-forwardly in most other languages, either, but there are some exceptions.

Such as Ruby, Scheme, and Smalltalk. And it just so happens that these are the only languages with web frameworks I can even tolerate.

Ruby and Scheme have a built-in and very convenient way of doing exactly what we want -- Smalltalk is powerful enough to let us build it. But in any case, the common operation used is called CALL/CC -- Call with Current Continuation. By 'continuation', the name is referring to the set of registers & the stack. With it, web frameworks that let you run my previous example can and have been implemented. Here is some actual code from a music manager I'm writing in Ruby:

      path = request "What path do you want to scan for music?", "Scan"      inform "Just a minute..."      @@library = Library.new      @@library.spider path      inform "Done!"

request asks the user for input in a web page with a form. inform shows a message in another page with an "OK" button. These lines of code together make up three different pages. And I didn't have to write a single form, or yet another fucking state machine.

This code is also directly yanked from my application:

  r.list_do @albums do |artist, album|    r.anchor "#{artist} - #{album}" do      add_album artist, album    end  end

list_do makes a HTML list, where the list items are gotten by repeatedly calling the block that is passed to it. anchor also takes a block, but the block is not run immediately. Instead, it is run when the anchor is clicked. And you don't have to write a fucking state machine.

This is the only sane way to do web programming.

Linux
Apache
mod_perl
Mysql

fast, clean, free, flexable.

the only sane way to do web programming :)

Quote:

Original post by torqueso Yet the problems are identical.

Except that they aren't. Web programming is much closer to traditional event-driven programming, which is exactly what ASP.NET tries to emulate.

Quote:

Original post by Arild Fines Quote: Original post by torqueso Yet the problems are identical. Except that they aren't. Web programming is much closer to traditional event-driven programming, which is exactly what ASP.NET tries to emulate.

Yes. That's what I hate. Thankfully it's a solved problem.

Quote:

You can't program that straight-forwardly in C, because the C language doesn't expose the registers to the programmer.

You mean, except for through the highly portable, standards-defined longjmp() function? Like, the one that about a zillion well portable fiber libraries have been written on top of?

If you like SmallTalk and find that there are implementations that suit your price/performance/scalability needs; great for you! But don't go spreading lies about other languages and environments; it just turns people against you.

Also, in your model, you forgot the problem with abandoned sessions; at a minimum, you have to add a time-out signal to your synchronous sessions.

Also, when you go synchronous, rather than session based, you cannot load balance between multiple servers without VERY EXPENSIVE state-based load balancers (which, in turn, have time-outs on their implicit idea of a "session"). So, again, different price/performance/scalability requirements for different people. Truth is good. Falsehood hurts you.

Quote:

Original post by hplus0603 Quote: You can't program that straight-forwardly in C, because the C language doesn't expose the registers to the programmer. You mean, except for through the highly portable, standards-defined longjmp() function? Like, the one that about a zillion well portable fiber libraries have been written on top of?

Oops -- I meant to say that there is no portable way of saving the registers and the stack. Portable fiber libraries have been written on top of longjmp and setjmp, but they have not been written in standard C.

Quote:

If you like SmallTalk and find that there are implementations that suit your price/performance/scalability needs; great for you! But don't go spreading lies about other languages and environments; it just turns people against you.

I like Ruby better. I will let people think whatever they want of me -- I don't care -- but I haven't intentionally spread any lies.

Quote:

Also, in your model, you forgot the problem with abandoned sessions; at a minimum, you have to add a time-out signal to your synchronous sessions.

I didn't forget it. I ignored it.

Quote:

Also, when you go synchronous, rather than session based, you cannot load balance between multiple servers without VERY EXPENSIVE state-based load balancers (which, in turn, have time-outs on their implicit idea of a "session").

I don't think you're wrong, but I don't see why, unless sessions must migrate between servers, which doesn't seem necessary.

Quote:

Original post by torqueso I want to program the web just as I program a terminal. Poor web frameworks don't let me. They force upon me the complexities of multiplexing between several clients. This is an example of bad factoring. The plurality of dialogues should be abstracted away.

Apache Cocoon has this type of functionality. It can be implemented in &#106avascript or Java. When someone accesses a certain URI, Cocoon will call a function that will handle user interaction. The function will call <code>sendPageAndWait</code> and execution is halted until the user submits the form. The actual logic can be done in &#106avascript, or you can call Java methods to handle it.<br><br>And to get back to the topic, my development setup includes:<br><ul><li>Apache httpd, MySQL, and PHP</li><br><li>Apache Tomcat</li><br><li>Apache Cocoon</li><br><li>Xcode (now with PHP syntax hilighting!)</li><br><li>BBEdit Lite</li><br><li>Mozilla (for &#106avascript/DOM debugging)</li><br><li>Subversion</li></ul><br><br><!--QUOTE--><BLOCKQUOTE><span class="smallfont">Quote:</span><table border=0 cellpadding=4 cellspacing=0 width="95%"><tr><td class=quote><!--/QUOTE--><!--STARTQUOTE-->I used to, but when IE emerged as 'the winner', I got lazy. Now the other browsers seem to be more standards compliant, so I'm thinking about developing to conform to the new standards.<!--QUOTE--></td></tr></table></BLOCKQUOTE><!--/QUOTE--><!--ENDQUOTE--><br><a href="http://www.internetnews.com/security/article.php/3374931">Here's another good reason</a><br><br><!--QUOTE--><BLOCKQUOTE><span class="smallfont">Quote:</span><table border=0 cellpadding=4 cellspacing=0 width="95%"><tr><td class=quote><!--/QUOTE--><!--STARTQUOTE-->How about XHTML, is there much interest in moving over to that in your development?<!--QUOTE--></td></tr></table></BLOCKQUOTE><!--/QUOTE--><!--ENDQUOTE-->That's a big, fat yes.

At the moment I'm using:

• On the server side:
  
  
  
  • Apache 2.0.49
    
  • MySQL 4.0.18
    
  • PHP 4.3.6.6
    
    
    
    • PEAR::DB
      
    • PEAR::HTML_QuickForm
      
    • PEAR::HTML_Template_IT (I'm interested by the XSLT way of
      doing it, but this works very well)
      
    
    
  
  
• On the client side:
  
  
  
  • XHTML 1.1
    
  • CSS 2.0 (well, I might not be using any of the functionality ;))
    
  
  
• Development side:
  
  
  
  • EditPlus 2
    
  • Subversion 1.0.1
    
  • TortoiseSVN 1.0.3
    
  • Mozilla Firefox 0.9.1
    
  
  

I use for developing my winXP Pro PC with:

Apache 1 (mostly for its staility)
PHP (always up to date)
MySQL (Free and easy)

Dreamweaver MX, and any notepad like to edit css and things like those.

IE6, Netscape, Opera, and Mozilla installed to test cross-browser compatibility

All my documents are XHTML - Transitional Compliant

I've stayed away from ASP for various reasons, one being that a lot of tools out there for ASP cost a whole load of money.

Apache 2.0.5
PHP 4.3.7
MySQL 4
CGI-bin
CSS, DHTML, XML, &#106avascript<br/><br/>I never write my code based on what IE likes. I develop Firefox (which means you're developing for 5 other browsers). If there are minor problems which are easy fixes (in IE) then I go for it. If it's being a bitch, I just forget about it. I detect IE users and direct them to using Firefox. :D<br/><br/>EDIT: Of course, I never do that for client projects.