jeffman

Who's operated a wiki before? My first guess is to just start off using MediaWiki, but I'm pretty much in the dark here.

I think it was the large staff and approval process I was thinking about. I assume, perhaps incorrectly, that Refsnes Data is stretched as far as they can go right now.Specifically, I worried about advertising on a site that could not protect itself against malicious posts within a reasonable period of maintenance.I suppose if Refsnes Data can talk rational people like JSG, boen and Synook into volunteering as mods for the board, they can do the same for a wiki. Eventually, a core group of wiki admins would be paid, just as they are at Wikipedia, and that would ensure even higher quality.Yes, I was short-sighted at first. A Wikipedia-style repository could become the defacto programming database. Maybe it is inevitable.As an academic, I have an interesting perspective on Wikipedia and its evolution. I've been using it personally for quite some time. As a teacher, though, I went along with the party-line that said to our students, "Oh, it's unreliable, stay away, don't even think of using it as a research tool."Then at some point I started noticing a lot of scholarly blogs linking to more and more articles there. Which is to say, the opinion of actual scholars toward the thing had begun to change. And I'm talking serious scholars, here, not just newly-minted PhDs.Recently, an article in The Chronicle of Higher Education argued that academics should (1) encourage students to use Wikipedia as a jumping-off place for deeper research, and (2) actually contribute to the knowledge base. #2 is already happening, but nowhere near as extensively as it could.The point is simple, and argues more strongly for JSG's idea. If a non-profit start-up like Wikipedia could become what it is in 10 years, AND earn the respect of professional scholars, then a web-programming wiki could do the same. Given the incredible SEO position that W3Schools enjoys, this probably is the right place. And now might be the right time.This is fun. Count me in.

I was thinking about the Wiki approach W3Fools suggested. It seems very dangerous to me. Refsnes Data ran this site with token advertising for a long time. The long-term goal was obviously to make money, and now the ads are getting a lot more space. I wish them well.The point is, Wiki sites like Wikipedia are hard to control. Wikipedia lives without advertising, and we all know that, good as it is, all it takes is one jerk to come along and mess up an article. Then you have the correction and discussion process.Does that work well when your goal is profit? I'm not so sure. Paid advertisers are likely to be put off by the chance that 24-72 hours could go by before something crazy has been fixed.I would suggest that Refsnes Data simply encourage a more lively suggestion forum. I think it would require one small change. A Refsnes representative could maintain a visible, semi-active presence on the suggestion forum. Asking questions, occasionally responding to suggestions, and actually acknowledging that a suggestion has been heard and acted upon. Really, I think you'd see a lot more active participation. And if more people post stoopid suggestions, too, what's the harm? It's easy enough to ignore that kind of stuff, and obvious trolls will get canned as usual.

I seem to have too much time on my hands: As strange as it may seem, the Intro page linked above is NOT the first page of the VBScript tutorial. This one is. Guess what you'll find at the top of the HOME page in BIG FREAKIN LETTERS:VBScript is a Microsoft scripting language.VBScript is the default scripting language in ASP.Client-side VBScript only works in Internet Explorer!The Tryit example on that page also makes it clear that it will work in IE only. In fact, almost every green-boxed example with a link to a Tryit in this tutorial clearly indicates that it's meant for IE only.Again, W3Fools is citing information missing from pages where it doesn't belong, and ignoring the fact that the information does appear on more appropriate pages. In this case, I'm tempted to conclude that W3Fools maliciously sought out and quoted one of the few pages in the VBS tutorial that doesn't mention the proprietary nature of VBS. I have no insight into the authors' minds, so I won't make an accusation. But, seriously, this one doesn't even pass the smell test.

Let's make this a trilogy: There is a complaint to be made here, but W3Fools missed it. W3Schools wants to be a complete reference. When you make that commitment, you don't get to cherry-pick the objects you're going to explain. You explain all of them, stupid or not.The thing is, I agree that the Boolean object is stupid. If the school edits this page, they should explain the pitfalls of using it and the benefits of using Boolean primitives. And that's all that W3Fools should have recommended. If they have a beef with JavaScript, they know who to send it to.

Also bothersome: For starters, false is a valid value and there are times when it is appropriate. Using it and promoting it are hardly the same thing. Never using it at all would suggest that it never gets used, and that would be an even greater sin.More to the point, the cited material is from a jQuery tutorial. The main AJAX tutorial is in a separate section, as it should be. Further, the example presented at the top of the request object tutorial shows asynch set to false, just as W3Fools suggests. I've seen AJAX stuff that people copy/pasta from the school, and it's stuff from this section.Continuing: a later section of the request object tutorial DOES address the different effects of using a true or false asynch value. Seems to me that this is the place to have that discussion, since it is (as I said) the main AJAX tutorial. If a jQuery student wants thorough documentation of AJAX, he should have brains enough to look for it here instead of there.By W3Fools' logic, every time an example uses the alert method, we should get a complete discussion of the window object!And just so we're clear on this, the request object tutorial has this to say: Any questions?

This one bugged me: W3Fools is wrong.1. W3Schools maintains different references for HTML 4.01 and 5. The quoted material is from the 4.01 section. The 5 section clearly indicates that these tags are not supported.2. According to the W3C specification, these tags are supported and not deprecated in 4.01. The same passage clearly indicates that <strike> and <u> are deprecated. I mention this only to demonstrate the unlikelihood that this section of the spec somehow forgot to mention which tags were deprecated.3. A comprehensive listing of HTML elements should describe ALL valid elements. That's pretty basic. Describing a valid element is NOT the same as advocating it.4. Indeed, adding that "it is possible to achieve richer effect with CSS" is not what I would call a mild disclaimer. It is actually pretty bold commentary on a site that strives to be informative and objective.W3Fools, you have some legitimate points to make. Someone should have done more homework before making this one.

So much effort put into so much anger, and probably to very little result. (E.g., I don't see newbies changing their Google habits.) I could kind of see a point if W3Fools had already sent the list of concerns to Refsnes Data and been rebuffed, but there is no indication of that. At least the link appears in the correct forum to initiate constructive action. Assuming the arrogant tone doesn't put off the audience. Right or wrong (mostly right) the tone certainly puts me off.

Just don't ever link to a site that would be considered a competitor to W3Schools.

Ruby on Rails is supposed to integrate well in shops that feature Rapid App Development and Agile Development. I don't know much about that stuff. I just hack.Maybe you'd get a better feel for these languages is you dropped in on some boards devoted to them.

Python is a few years older than PHP, Ruby is about the same age. A lot of younger businesses and developers are very fired up about them. I am not certain, but I do not believe the default installation of either language comes close to the built-in stuff offered by PHP. Maybe if you like including a lot of external libraries, the way you have to in C or Perl, that wouldn't be so bad.I personally dislike languages delimited by whitespace (Python) or that use end statements (Ruby). But that's pretty personal. I CAN program in Visual Basic and its ilk, but I do not like it.

The HTML5 specification is still in the Draft stage. No browser manufacturer is going to fully implement all its features until shortly before it is finalized and upgraded to the Recommendation stage. Many page designers choose to use almost no HTML5 features, except those that have been incorporated by ALL major browsers, including IE7. It's a short list.As parts of the HTML5 spec become more and more certain, browsers manufacturers are implementing more and more of it. Every Firefox upgrade seems to add 1-2 more features. Taking advantage of these features requires a developer to read the documentation very carefully every time a browser releases a new version. And that means tracking ALL the major browsers. A lot of work.The biggest problem comes when you try to accommodate older browsers that are still in widespread use, like (again) IE7. A site that DEPENDS on certain HTML5 features that currently work only in Chrome, say, or only in Firefox, is likely to have a lot of frustrated users. As we learned back in the "browser wars" in the 1990s, adding little notices like "Optimized for Chrome" is not a popular solution.Visit a corporate page that gets a million hits every day. You won't find a lot of HTML5. That should tell you something.

I recommend Firefox as a testing environment for all new developers (and even mid-life developers) because the built-in Error Console is easy to use and identifies most problems. It is not a sophisticated debugger, but that is its strength. There is almost no learning curve. If you want an easy debugging solution that detects most of your CSS and JS problems, you cannot beat the Firefox Error Console. Seriously. A huge number of "problems" that people bring to this board can easily be solved just by looking at your Error Console.The only "trick" is remembering to clear it before you load your page, because it is always on and records errors on EVERY page you visit. Your errors will be reported at the end, which is why many new developers don't even realize they are there. Clear the console, load your page, and look at the errors that apply to your page only. If you run a script in response to button clicks and so on, you may need to look at the console several times during the life of your page.Advanced developers require more advanced tools. That is not the point I am discussing in this post.

I'll second that. Many Mac users are familiar with BBEdit, which has been around forever and adds features all the time. TextWrangler is Bare Bones's free version of BBEdit, so you know it's a good piece of software.TextWrangler has the added benefit of being able to see and edit all those "hidden" files used by the Unix layer, in case you ever want to change some of your more esoteric system settings.

For some of us, features like auto-completion and syntax highlighting are the only reasons to use a dedicated editor. But nomnex's plan sounds like good practice for learning.

Welcome Beverly. Taking classes can certainly help and look good on a resume. Look for a school that has a real web design program or area. An IT department where they mostly have word processing and spreadsheet-type classes, and just 1-2 web classes, might be clueless, and you could actually learn obsolete stuff. I'm not saying all are like that, but there are plenty. I am a college professor. I know.

Game console. Got it. Sorry if I introduced some confusion.

It's not the programming language that makes something easier to pick up. It's the API. JavaScript is a great learning tool if you treat the browser like a console (ie, just basic input output). But if you really want to learn about programming (the biggest difference, in my experience, is memory management) then any IDE that works with a console is a good start. In other words, stay away from the GUI interface until you understand what you're doing. I'm old-school, so I would personally recommend C as your first language. From there you can go to Java or C++, and that would mostly be an expansion of your skills, not starting from scratch. Again, stick with the console approach before you try a GUI. The nice thing about IDEs that operate in a console only is you can usually find FREE ones; just download them.

Not a bad example. You can see an immediate issue that might trap the unsuspecting developer. Let's add some statements prior to that mess:c=0;d=0;for(;;e++)if(g)a=b?c++&f:--d;What are the values of c and d when the ternary is first evaluated?(1) c == 0; d == 0(2) c == 1; d == -1(3) c == 0; d == -1(4) c == 1; d == 0

I think the issue with increment operators is entirely psychological.1. developers might forget the difference between a post-increment and a pre-increment when embedding increments in a complex statement.The solution is to not use write code so terse that increments are embedded in complex statements. It is not 1969. We can waste a few bytes to make code more readable.2. developers might make mistakes if they use multiple statements in the 3rd section of a for-loop initializer, and somehow the different statements involve the same variable.The solution is to not do that. Again, we do not really need to save bytes, and there is almost never a good reason to include multiple statements in any segment of a for-loop initializer. Old-time C programmers may like to write really terse code, but it's really not necessary, especially in a scripting environment like JavaScript or PHP.

Hi, Toni. Congratulations on taking up a challenging hobby at age 66. And also for being older than I am. :)I like your goal of helping others. One of the reason I and some of the other regulars come here to help out is that it gives us a chance to solve problems we might not otherwise have thought up. I don't always test out code for people (some stuff is pretty routine) but I often do, and I almost always learn something.That's how they do it in med school: see one, do one, teach one. The teaching part is when you really learn what it's all about.And even if you don't teach anything for a while, you can still learn a lot on the forum. You just have to follow it a lot and see what kinds of solutions people come up with. A lot of this stuff comes from experience and cannot be found in textbooks at any price. Seriously.

Pretty good work for 18. Three suggestions off the top of my head.1. Don't blink elements, or at most let them blink once and stop. Most users find them distracting. The "cool" factor wears off very quickly.2. Don't use tables as a layout framework, as you do in "navigation2." The list format you use in the next menu could be applied to this one.3. Learn how to anti-alias your graphics, to remove the jaggies.

TESTING POST & AJAX SCRIPTSThis is a very simple technique that others must have discovered before me, but I don't recall seeing it mentioned anywhere, on this board or otherwise. Maybe because it's so incredibly obvious, or so incredibly wrong? FWIW, here it is.The problem. You design a PHP script that receives POST data. Testing it as written requires a form or AJAX. Maybe you have such a form already embedded in your page. If not, you must create one to test the script. Testing a script that you communicate with by AJAX is even trickier. Because data you echo isn't automatically displayed, you have to hack up your javascript with alerts and so forth to see what the responseText is.Wouldn't it be nice to run such a script right from your address bar? The results would appear immediately in your browser.Two things stand in the way. First, address-bar requests are GET requests. If your script extracts data from the $_POST array, no data will be there. Second: If you are using sessions for security, your script may require that a user be logged in before the script can be run.A partial solution is to write your script using the $_REQUEST array instead of the $_POST array. Now you can put test data into your ?query string and the script will not care if it comes by POST or GET. But using $_REQUEST is bad practice, so you'll have to go back and change all those references before your script is ready for action. That's extra work and creates the chance of a mistake (you might neglect to change one). And this does nothing to solve the login problem. For that, you'll have to comment out lines that reference the $_SESSION array. This is also extra work and creates chances for mistakes.A solution. Add the following line to the top of your script, right after your session_start statement (if you have one): $_POST = $_SESSION = &$_GET; Now you can test your script from your browser's address bar. Put all the POST and SESSION data your script requires into a big ?query string. (This might mean a lot of typing, but you'll only have to do most of it once.) The GET data gets copied into the $_POST array, and any existing SESSION data gets overwritten.Advantages:1. You can run your script in what is essentially a command-line environment.2. No login is required, so you don't have to worry about session timeout.3. No forms to load means not having to troubleshoot the form mechanism while you're testing the PHP mechanism.4. Same with AJAX.5. Instant feedback on scripts meant to run in an AJAX environment. Easy debugging that requires no changes to your javascript or HTML just for debugging purposes.6. The whole trick requires one line of code that can be deleted or commented out very easily.7. Depending on your set-up, cookie data will automatically be available as usual.8. Low overhead, if it matters, since we're copying the $_GET array by reference.Disadvantages:1. You can't transmit a lot of data into a GET request, and browsers limit the length of URLs permitted in the address bar. Smaller bits of test data may not be sufficient for some applications. (The limit is still pretty big, though. IE allows up to 2048 characters in the address bar. That's as long as a two-page essay.)2. You may need long, complicated query strings. (Copy/paste can simplify this problem. It also gives you the chance to really look at your data. It's real easy to muff a comma in a JSON string, and this technique lets you construct one that is 100% correct.)3. Potential security issues if you're developing in office-cubicle or school-lab environments.4. If your script uses the same keys in multiple superglobal arrays, they'll all evaluate to the same value. Chances are good they would do that anyway, but not in all situations, and part of your testing may involve routines for when they are different. I haven't thought of a way around this that doesn't involve modifying your script (which kind of defeats the purpose).Anyway, that's my Thanksgiving contribution to this thread. If anyone sees something stoopid I've missed, please show me. If the whole plan is wrongheaded, I'll just Hoover this post. If it needs tweaking, I'll tweak it.

I haven't checked it in FF3.5, but execCommand () used to work fine in FF (Safari, too, for that matter). But the permitted functions were always more security-minded than the IE implementation that it imitates. Since "copy" affects the system-wide clipboard (it does, right?) FF/Mozilla may have decided that that extends the scope of javascript too far. As a user, I know I wouldn't want my clipboard subject to a page-designer's whim. Functions like "bold" and "forecolor" always worked fine.

Nice to see younger folks into the classics. I have a 12-yr-old daughter who likes Star Trek, but only because it was something we did together one summer. I look forward to the new movie, but I worry about it too. The trailers make it clear the new production will mess with established "history," but I like JJ Abrams's other stuff, especially LOST. So we'll see.