Resig’s jQuery is so powerful and so easy that even with basic knowledge of CSS and Javascript, anyone can be a virtual scripting master.  It’s so easy, that I’ve slacked on learning about javascript objects, inheritance, closures, anonymous functions, prototypes, and scores of  other Javascript staples that I should’ve long since mastered.   I just discovered John’s new web app, cleverly titled “Learning Advanced Javascript“, and so far, so good!

I wrote this myself and understand why it works, which is much more than I could say yesterday.

var ninja = {
	walk: function(steps,turn) {
		toDo = 'Walking '+steps+' steps forward, then turning '+turn;
		return this;
	  },
	star: function(action,distance) {
		toDo = toDo+' '+action+'ing star '+distance+' feet'; return this;
	  },
	then: function() {
		toDo = toDo+', then '; return this;
	},
	doIt: function() {
		log(toDo);
	}
}
ninja.walk('7','south').then().star('throw','50').doIt();

Output:

> Walking 7 steps forward, then turning south, then throwing star 50 feet

It’s clear to me – and has been for some time – that the future of the web, for better or for worse, rests heavily on the mighty shoulders of client side scripting.   Building on powerful, extensible frameworks like jQuery and MooTools, the next generation of web apps is sure to compete with the desktop.  The ability to understand how to utilize the frameworks when necessary and hack together powerful scriptlets for other purposes seems essential to success in the future web. I know I’ll be investing in “Secrets of a Javascript Ninja” just as a result of this tutorial.

One of the things I (used to) do as Small Axe Solutions was publish the core code of the engine that powers firsttube.com, Small Axe. Small Axe code was built up as 0.1, then 0.2, then 0.3. At that point, I had added several features to firsttube.com that I had yet to merge upstream into Small Axe. So, I created a build system so I could slowly integrate the changes. In short, it worked like this: I had a directory called “build_source” which contained my current code. Of course, it had all kinds of problems out of the box, like the config files which pointed to nonsensical location like /path/to/your/blog/. It had no valid database connection info. The flatfiles were unwritable. So, in short, the code was (usually) solid, but PHP couldn’t compile it.

Meanwhile, another directory called “demo” was waiting silently.

Lastly, a third directory, outside the web root, called “static” was sitting with pre-built config files, db connection files, and some other stuff.

Then it was just a matter of a simple shell script. The script did the following: it deleted everything in the “demo” directory. Then it copied all of the files in the “build_source” directory into the demo directory. It deleted the config file and overwrote it with a copy from the “static” directory. Same for the db connection and a few other files. It left the demo directory as a live, fully functional build of the current code. Then it zipped everything in the “build_source” directory and put it into my downloads section. It ran this script every 30 minutes for probably 2 years now. I only chose 30 minutes because it made sense from a development standpoint to see the updates quickly. I stopped working on that version some time ago, but never got around to updating or changing the script.

Fast forward to a few weeks ago, I was cleaning out a bunch of old directories. Within 5 minutes, EVERYTHING was gone: my mail, *all* of my sites, my temp files, everything in my home directory that wasn’t a hidden file preceded with a dot. I didn’t realize this for several hours, but I then I restored from a backup and within 45 minutes, everything was gone again! Oh noes!

I immediately begin researching security and disabling all of my upload scripts. Something is wrong, I thought. I searched high and low. But, as you guessed, I didn’t find anything wrong, because there was nothing wrong. In my cleanup, as you may have gussed by now, I decided to delete the “demo” folder. The first line of my shell script is “cd /home/adam/public_html/build_source.” Then second, scary line, is “rm -rf *“. Since there was no “build_source” folder, the first line flat out failed, leaving the script in /home/adam. Then, unfortunately, it ran rm -rf * in the root of my home directory. Killer!

It took my some time to swallow my own stupidity. All I had to do was comment out the cron job to prevent this disaster. But alas, I dropped the ball. We’re back online now, and a little smarter.

Start by adding this to your javascript file:

function blinkId(id) {
	var i = document.getElementById(id);
	if(i.style.visibility=='hidden') {
		i.style.visibility='visible';
	} else {
		i.style.visibility='hidden';
	}
    setTimeout("blinkId('"+id+"')",1000);
	return true;
}

And this right before you end your <html> tag:

<script type="text/javascript">blinkId('YOUR_ELEMENT_ID');</script>

This will work for images, divs, spans, pretty much any block level element with an id.

Updated 8/19/2008: Fixed a copy/paste bug in this post.

Why? Let’s argue for a second that everything people say about PHP is true, as many of the complaints are sound.

It’s true the primary namespace has way too many functions – over three thousand, I’m told. It’s true that the function names are inconsistent, some have underscores, some don’t. It’s true that the function names are often verbose. It’s true that OOP was weak until recently, it’s true that register_globals was a security nightmare. All those things are potential issues, and all languages have them. As the “real programmers” who write Perl would never admit, reading other people’s terse Perl is often a f’ing disaster, even for seasoned Perl-ites. And when using compiled ASP.net – for best performance, natch – you must update your entire site (well, all the concerned ASPX pages and DLLs) to make elementary changes.

That said, PHP is easy. Really easy. And it’s a trivial task to get a website up and running fairly quickly. And you can serve enormous amounts of traffic as proven not only by OSNews (who have been dugg and Slashdotted concurrently), but by Yahoo!, Wikipedia, Flickr, Facebook, and many, many others. And why are there so many open source PHP frameworks, apps, CMSes, etc? Because PHP is installable virtually everywhere, it’s very portable, and it’s really simple to hack up. Try installing something dependent on mod_perl (e.g. Slash or Scoop) and get back to me on the ease of the install.

The fact is, even if everyone’s fears about writing insecure code is true, the ability to make mistakes does not mean everyone does, and those who would forsake “the right tool for the job at hand” shouldn’t be trusted even to water your plants, because they are obviously nitwits. If you can’t concede that PHP can be the right tool some of the time for some situations, you shouldn’t be trusted to code or make adult decisions. No, I argue that the reason they dislike PHP is because many start with PHP and thus, admitting to liking it would make them appear to be a “noob.” It’s because they must appear to be seasoned pros. It’s the bragging rights on the 21st century.

Nobody has ever claimed PHP is the solution to everything, but it is a remarkably easy tool for scripting dynamically generated HTML. And, in my opinion and experience, it does so better than Perl, better than Ruby, and a hell of a lot better than both ASP.net and JSP.

iDope currently has a lot of bugs. Mainly, your jacket storage is irrelevant, you can actually store unlimited items, you just can’t buy unlimited items unless you hit “buy all.” You can’t store money in a bank. It never ends until you die. You are mugged or fight the cops maybe 80% of the time you travel. But most importantly, this:

Notice my dollars? That’s right, I have $2,147,483,647. Two billion, one hundred forty seven million, four hundred eighty three thousand, six hundred forty seven dollars. Recognize that number? If you read my blog regularly, you might. After all, it’s the upper limit of signed integers. The game is officially boring – no matter what I do, I’m always capped at that number, I can never get more money. I wonder if the iPhone can support BIGINT.

Anyway, I really hope to see iDope get some love and attention, because Dope Wars is a fabulous and addictive game, but as is, I eventually get to the upper limit and have to start over… and over… and over.

So, I got a phone call from the director of our customer contact department this week. He was concerned about the reports. He made a decision last week that when a call came in that was a lead – in other words, a non-customer, that his people would fill the phone number from the caller ID into the account number field. But when he ran his export reports, he found that hisn techs had entered this phone number for ALL of the calls: 429-496-7295. That’s weird, he said. So he called me and asked why that was. I checked all the calls and most were from one woman, so my first instinct was “Check if her browser has autocomplete turned on”. But he swore that he tried it too and gotten the same result.

I checked the database and sure enough, it was right there: 429-496-7295, in all of the fields. So I went back to the code. In short, I took the input from the form, and declared it like this:

$accountnum = (int) $_POST['accountnum'];

Pretty straightforward: explicitly declare the type. So, I started my debugging by attempting to manually enter the data into the database. Sure enough: the account key field showed this: 4294967295.

So, I went back to the PHP and started by dumping out the raw SQL query:

INSERT INTO calls ('','x','x','x','4294967295','x','x');

What? So the database automatically converts it to this weird phone number and PHP does too? Suddenly it occured to me. One of the benefits of 64-bit computing is the ability to address more memory. There are limits to what can be done in 32-bit computing, and one is that integers have a limit! In this case, a database field called “integer” is limited to numbers between -2,147,483,648 and +2,147,483,647. It just so happens that the number is the same length as a US phone number – 10 digits. Changing the db field to “BIGINT” allowed me to manually run the SQL query and it worked. But the app still didn’t.

PHP’s int() and (int) $var syntaxes both conform to the integer limit. So I devised a work around:

$ac = $_POST['accountnum'];
if(!is_numeric($ac) { $ac = (int) $ac; }

It’s not gorgeous, but it will more than suffice for an internal app. We web programmers don’t usually have to deal with big integers, so it’s totally possible that web developers would never have had occasion to handle a situation like this. Here’s looking forward to native 64-bit for our next server, though.

As of today, we have AJAX moderation, super improved comment reply mechanism that allows you to quote an author, and a new, experimental system called “starring,” not stolen from Google but awfully like it. You can “star” stories much like a story bookmark, you can bookmark comments to later refer to, and you can “recommend” stories, which are stories you think other OSNews readers should check out.

I also added a nice touch feature – user avatars. I think avatars help users to recognize each other, and they add some “spice” to an otherwise simple look. I’m pretty excited about it, but obviously will not be building the upload form until my image resize scripts are ready. I generated my own avatar, now I need to find a nice way to resize in a secure fashion. It’s all very cool. To do what sites like Flickr do, I think I’d need Flash, so it’s pretty simple: you upload and I resize to avatar dimensions.

So moderation is all AJAX based now, which is really super cool, and works just like you’d expect – you can vote up or down, the score updates, the comment collapses when voting down… it’s exactly what I wanted when I envisioned it. Soon it will throw useful error messages instead of v3 error “codes.”

I hope to have the comment and submission forms working soon. If all goes well, we’ll do a public beta in February or March and rollout this spring. Promises to be very exciting.

I’ve also discarded the concept of “collapsed threading” vs. “expanded threading.” All threads will be expanded, because it’s less code and it’s easier to maintain. Building on that, comments below your “threshold” will not require a reload, but rather just an “expand” to be viewed. Lots of things, like viewing below-threshold comments, moderation, etc will not require a page load. Only some of this requires actual AJAX, the rest is just Javascript.

I’ve also cleaned up the URIs quite a bit. First off, pages no longer have a file extension. If we one day rewrite the site in Python, or Ruby on Rails, or whatever, we’ll be future compatible. I will be redircting all working pages to the proper page in the new site, so links will still work. It will be nice to reference my comments at www.osnews.com/user/ascheinberg/comments, my bookmarks at www.osnews.com/user/ascheinberg/bookmarks, my “starred stories” (more on that below) at www.osnews.com/user/ascheinberg/starred, my friends and fans at www.osnews.com/user/ascheinberg/relationships, and my public profile at just www.osnews.com/user/ascheinberg.

That said, several of the pages that exist now will go bye-bye in favor of better organized pages. Besides just the user info pages, you’ll find that thread.php, subthread.php, permalink.php, read_thread.php all pretty much capture the same information. Also, reply.php will be blended with the regular comment posting section. So a code cleanup is in order.

I’m rewriting in XHTML, although I’m not worrying about validation just yet. That said, it’s almost entirely styled with CSS, and thus far, there are no tables. That’s not to say there will not be several tables, but for now, layout is solely CSS.

I came up with the concept of “starred stories” because I want to make “recommendations” more of a suggestion for other readers. I will be expanding on this point in future posts, but trust me, it will make sense or it will be left out.

I also am currently supporting something I’ve not decided on: avatars. It’s not necessary, but since I wrote an image resizing script for the admin backend for automatic thumbnailing of screenshots, I can easily support an automatic resize for avatars, and honestly, they look nice.

The threading implementation, believe it or not, is actually faster than the current implementation because it’s much sleeker code. I’s very cool to quickly switch between thresholds and view modes without setting cookies or updating profiles.

One of the very cool features I’ve already got working is pretty much a tagging system, except instead of liberal use of tags, it will be used to “group” stories. Let’s say it’s time for WinHEC – we can group all stories from there as “WinHEC 2007″ or something. Or “CES.” Or “Macworld,” “LinuxExpo,” or even “Fedora Core 7.” It remains to be seen HOW we will use this system, but it’s already in the actual live database. Note that it will NOT show up in the current version of OSNews (v3).

Lastly, for today’s OSN4 details, I have one more fun feature I’ve toyed with for some time: user defined conversations. Essentially, it allows users to create their own OSNews article, or even just a blurb for discussion. I don’t know the specifics, this isn’t coded yet, but I think this could be really neat – let’s say you start a conversation: “Predict the specs for the next macbooks” or “Your experiences with Windows Vista.” Could be fun, right? We’ll see whether or not this turns out to make the cut.

Lastly, I want to share one more thing: RSS everywhere. Every relevant page will have an RSS feed. I’m excited about this.

So far, I have a working site that displays the main pages (the index, the story page, and the comment pages, with a working working threading implementation). More as it comes.

As always, all of this OSN4 stuff is subject to change.

So when I wrote OSNews, I respected Eugenia’s original decision to go flat. But the 15 comments per page is obviously driving by one thing and one thing only – increasing page views. Believe it or not, it’s much easier on the database to present all comments at once. For OSNews version 4, if you choose flat mode, it will be all comments at once on one page, period.

I added threading for two reasons: first and foremost, we had SO MANY users asking for it. I have the emails archived to prove it. It was the #1 most requested feature (along with comment editing, which I also implemented).

The second reason, to be honest, was because *I* wanted it. You see, readers tend to view things in the order they are presented, and they often respond without quoting a comment, so you tend to get comments like “Yes” or “I agree” or “Because the…” With threading, you can easily following multiple conversations. To me, threading makes much more sense than a flat view, because often times there are several sub-discussions in any given discussion.

So, I just completed a new section of OSNews, and for this section, I was completely unfettered. So I did some things:

• All comments are displayed in one page, period.
• Threading is mandatory
• However, threading can only be one level deep. In other words, you can reply to a new comment, but not to replies. To reply to a reply, you must reply to the original comment and discussion are tracked that way.

A lot of the crazy code that threading generates comes from supporting infinite replies. This will change in OSN4; not the structure of the database, just in the presentation (or lack thereof) of the reply/quote functions.

Also, for this new OSNews section, there is no registration. Any personal setting are done via cookies, nothing is kept on the server. This makes it easier to partake without deciding to pass it over because of registration. Of course, the issue here is that anyone can use any name and therefore impersonate someone else, but this is a small issue for a low traffic site. What I’m getting at is that this is a standard setting and not customizable like the views on OSNews.

So I remain mixed on threading. I understand that a flat view is generally easier to follow for the average Joe, but I simply don’t think that you should always cater to the dumbest possible user and build from there. There are those who do cater to the least technical user, there are those whose work suffers because they end up with a bland compromise, and there are those who simply man up and make the decision. Threading makes things easier to follow for *most* people with web experience, and that’s why I endorse it. Because the heaviest participation on websites is from those who are comfortable online, and therefore, will probably appreciate the threads.

1. This version is more secure – it won’t let the content of the feed break your HTML. Update: Apparently, the desired behavior is to render the HTML, not to preserve the markup as markup, so the new version Eugenia has released reflects that change. So code will be rendered, including javascript, so beware!!
2. This version outputs friendly errors. The 1.0 version can fail if your php.ini isn’t set up right, or output a blank page if there are certain errors.
3. This version is more portable and doesn’t rely on a particular PHP configuration.
4. Most differently, this version can cache the results. This way, each reload won’t hammer an RSS feed. Rather, the results can be cached for a perdiod and fed from cache, and then when the cache expires, it reloads the cache.

The source code is here: MobileQuo. Note that you will need to upload a blank WRITABLE file in your MobileQuo directory. Then just use the rest of the code from Eugenia here.

There were a few challenges. For one, the plus character has significance in the URL, so apps like, say, GTK+, are inaccessible. So now we dynamically convert those titles to something like GTK_Plus. Also, spaces are switched to underscores. The one thing that burned me was that some apps have names that include strings like Sunbird/Calendar, which is not only URL significant, but it also breaks the code. So unfortunately, we have convert those to pipes right now, so an app such as the previously mentioned Mozilla Sunbird/Calendar is now available at http://gnomefiles.org/app.php/Mozilla_Sunbird|Calendar. Until I have a better way to pull this off, / becomes a pipe.

However, for nearly all other apps, you’ve now got a very pretty URL. Fear not, your old URLs still work, but you’ll probably want to update your incoming links to point to the new style URL.