Posts Tagged ‘Programming’
I needed to have an image blink in one of our intranet applications today, so I wrote this quick javascript to accomodate. There aren’t many good image blinker scripts online, so I’m adding mine to the mix:
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.
Currently, over on Slashdot, there is an article on forthcoming features in PHP version 6. And, like most PHP articles, the comments section is flooded with jackasses arguing that PHP sucks as a language. I get frustrated by the entire “PHP sucks” campaign, largely because it’s like the HTML e-mail argument – mostly driven by the fact that it’s stylish to hate them – but I’m going to go further. I argue than everyone posting about how PHP is a bad language as a whole is an idiot. Every single one. Each is a foolish, arrogant, nerd sheep who can’t think for themselves. Update 5/14/08 20:39 UTC: Okay, this piece was linked by several sources, and the truth is, I had just read some George Carlin, so I was probably more aggressive than I intended to be. What I really mean is that people posting about how PHP is a bad language as a whole without citing any reasons are generally following a trend, trying to look cool, or too narrow-minded to be considered credible. And the responses I’ve seen across the net have, thus far, supported this argument.
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.
I love my jailbroken iPhone, and I am always looking for a new “game of the week.” I’ve been through several, at first, it was LightsOff, but that ends at 225 levels or so. Then it was Five Dice. Then 4 Balls, Domino, and finally PuzzleManiak. I was so happy recently when someone decided to port Dope Wars to the iPhone in the form of “iDope.”
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.
Some time ago, I wrote an application for my company. Like most weblets I’ve written, this used PHP and either MySQL or MSSQL for the backend. This particular application logged all phone calls. As part of the record, it would record the caller’s account number, which is a 5 or 6 digit integer.
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.
I have carried on more than I probably should about OSNews 4 recently, but it’s because I’ve been doing so much work on it. The site is mostly functional – nearly all the heaviest lifting is done, large parts are implemented and working.
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 saw an article today called Flat or Threaded? which examines the practice of “threading” a web forum. This has lead me to do some serious thinking about threading. Read on for more…
Eugenia released a little web-let called “MobileQuo” the other day, and it caught my eye. I downloaded it and hacked it up and made some changes.
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.
So Eugenia IM’ed me and told me that GNOME was pretty insistent about the fact that they wanted to see Gnomefiles clean up the URLs to make them more friendly. She asked me how hard the move would be. Having already dug pretty deep into GF code, I knew that it wouldn’t take too much effort to clean things up. So, just a few days later, I’m pretty sure we’ve gotten all the bugs ironed out. Apps are now accessed like this: http://gnomefiles.org/app.php/[appname] where [appname] is, obviously, the name of the application.
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.
I have several websites. The way my web host has them set up, like many hosts who use cPanel, is that one site is a “master” and the others essentially exist as directories within that site. My master site is smallaxesolutions.com, which is the “company” under which I sometimes do my web design and network support business.
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.