September 5th, 2010 — Coding, JavaScript, JQuery
In which I program with JavaScript and JQuery 1.1.4, write a sample HTML and JavaScript page to add two numbers together. And fail.
The goal:
This was a goal in writing a program in JavaScript to add two numbers. I picked jQuery as the “less evil than working directly in the DOM” solution. The entire application runs in one web page. Writing this program was significantly harder than a “hello world” program, but still manageable. At least, easy to get sort of working.
Step 1: Find the tools.
JQuery is the emerging library of choice for working in JavaScript. It smooths over most of the odd differences between browsers and brings a little sanity to the world. There are a million extensions for better UI elements, form validation, and such. I stuck to the basic jQuery for its stability and popularity.
As a library, jQuery is just a big JavaScript file which defines a couple entry points into a library of functions. It gets little enhancements between versions; while I used version 1.4.2, your experience and knowledge will work for future versions. You can read the jQuery source code, and Paul Irish has a great screencast of what they learned by reading it. As long as you are watching video, you should watch JavaScript, the Good Parts.
Next, I looked at tools. I tried to use Eclipse, and installed the web editor. I looked at Aptana, which is a customized version of Eclipse, though it didn’t really help either. The w3schools TryIt box gave instant feedback for little tests. I also used FireBug with FireQuery, which worked exceedingly well. FireBug is an extension to FireFox that debugs web pages and JavaScript; FireQuery adds clean debugging for jQuery calls. My final toolset ended up as Vim, FireBug and FireQuery.
JQuery documentation works well. Most quick Google hits for docuementation ended up at the jQuery site. Also, the w3Schools jQuery tutorial provides good information. Also helping was a random chunk of code from a friend’s large JavaScript project. I use Safari Books Online for books, and skimmed the JavaScript the Good Parts book. I also evaluated some the of the books on jQuery. I looked at quick reference sheets. My advice is to skip all the books, stick to Google and w3schools.
Step 2: The Application
My application had a simple defined goal:
Have two input boxes. When a number is entered into an input box, the sum of the two input boxes is updated whenever the boxes are changed.
I downloaded the latest version of jQuery. Grab the ‘Development Version’, meaning the uncompressed version that you need to Save As “jquery.js”. I found it faster for development to stick my JavaScript into my HTML file. Here is my basic “hello world” to see the parts work:
<html>
<head>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript">
/* Ready function called once after loading */
$(document).ready(function(){
$("#bang").html("<b> Go jQuery Go! </b>");
});
</script>
</head>
<body>
<div id="bang"></div>
</body>
</html>
All the JavaScript in all my examples was inside that ready() call. Keeping the indentation straight in the nested mess is a pain, and I would occasionally just ignore it for a while. Also, I kept getting the wrong prefix (#id, .class, or selector) as well has trying to use the wrong HTML tag attribute (id, class, name, etc.). The script would happily go forward, but without any valid values or updates. For example, were I to type:
$(".bang").html("Stop, Javascript, stop!");
the system would quietly go its way ignoring this line. This was the most common error I made in coding.
I found myself going back to quick and dirty debugging, checking each line for some silly error. I would throw up debug messages in alert boxes, which pause execution:
<script type="text/javascript">
/* Ready function called once after loading */
alert("In Script");
$(document).ready(function(){
alert("In ready")
$("#bang").html("<b> Go jQuery Go! </b>");
alert("Just set it. Html is now" + $("#bang").html());
});
</script>
This gets choppy quickly as the alert boxes pile up. I used this construct and added a ‘<div id=”messages”></div>‘ to have a long line of running messages:
var messages = "";
function update_message(a_message) {
$("#messages").html("<b>" + a_message + "</b>:" + messages);
messages = a_message + ':' + messages;
} ;
update_message("Running");
...
update_message("step 2. X = " + x + "and y = " + y);
Sometimes I would use the breakpoint in FireBug to stop the code in the correct scope and start typing expressions in the console. Sometimes FireBug would find syntax errors if I noticed the ‘ERROR’ indicator on the bottom of the screen. Remember the JavaScript, jQuery, HTML, and CSS are all utterly silent on most typos, so “don’t trust and verify” is your mantra. You can disable the test code by commenting out the function body.
I ended up with this basic code:
<html>
<head>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript">
/* Ready function called once after loading */
$(document).ready(function(){
var new_sum = function() {
//$('#sum_value').html('in new_sum' + Math.random() + ' ' + $('#sum_value') + "." + $('[name=first_number]').val() + "+" + $('[name=second_number]').val());
update_message("in new_sum");
var first = $('[name=first_number]').val();
var second = $('[name=second_number]').val();
var total = parseFloat(first) + parseFloat(second);
$('#sum_value').html(total);
update_message("first [" + first + "] second [" + second + "] total [" + total + "]");
}
var messages = "";
function update_message(a_message) {
$("#messages").html("<b>" + a_message + "</b>:" + messages);
messages = a_message + ':' + messages;
} ;
update_message("Running");
$('.numbers').change(function() { update_message("change"); new_sum();} );
$('#sum_value').html('no sum yet.');
});
</script>
</head>
<body>
<div id="messages"></div>
<div id="title1">First Number</div>
<input type="text" name="first_number" value="1" />
<div id="title2">Second Number</div>
<input type="text" name="second_number" value="2" />
<div id="sum_title">Sum</div>
<div id="sum_value"></div>
</body>
</html>
Yes, JavaScript and HTML both get verbose quickly. I think the verbosity encourages the lack of comments, white space, and the long chained function calls commonly found in this type of code. Of course, one could always claim ‘performance’.
Step 3: The Event Bugs
If you play with the code, you will find it doesn’t quite work. You need to switch away from the text field before the change event gets called. The situation gets better by catching not just the change event but also keyup and click. It still gets broken on cut and paste. I looked at Stack Overflow questions, read available documentation, experimented, and figured out that the program will never quite work.
jQuery is built on JavaScript and the HTML standards. These standards are fundamentally flawed, though some flaws get fixed like upkeep on an old house. Most GUI toolkits would have a pair of events for “About to change value” and “Value was just changed.”. HTML and JavaScript do not. I can catch the cut and paste events before they make a change, wait some time, and hope to catch it after the event was processed. I can make a busy loop which just updates the total every little bit of time. Still, it will never be perfect. “Good enough” appears to be the mantra for web programming.
So, that’s the experiment. It took about a day, mostly figuring out the event bugs and that the problem could not be properly fixed. As always, if there enough questions or comments, I’ll expand the blog entry.
August 17th, 2010 — Coding
Have a small Bash shell function to serve the current Git distributed version control system repository from a remote host. The second time I needed to do this, it was time to add a function tomy .bash_site file. Enjoy:
# Serve this repository from a remote host.
# Run without arguments from the current directory, puts a new repository
# on $remote_host, and let's you do "git push" commands. Thanks to
# ToolManTim who wrote http://toolmantim.com/thoughts/setting_up_a_new_remote_git_repository
# a few years back.
git-serve () {
# set remote_host to name in your .ssh/config file.
remote_host='dream'
repo_name=$(basename $PWD)
# if current directory a git repo and name not taken on remote.
if [ -d .git ] && [ $(ssh $remote_host "ls git/$repo_name 2> /dev/null" | wc -c) -eq 0 ]
then
ssh $remote_host "mkdir -p git/$repo_name && cd git/$repo_name && git init --bare"
git remote add origin $remote_host:git/$repo_name
git push origin master
echo '[branch "master"]
remote = origin
merge = refs/heads/master
' >> .git/config
echo "Set up the repository on $remote_host in git/$repo_name. Please double check your .git/config file:"
cat .git/config
else
echo "Current directory not a repository (no .git) or name taken at $remote_host:git/$repo_name"
fi
unset remote_host repo_name
}
So here is an example working with a small, existing repository:
chasm:(master)~/junk$ ls -a
. .. .git hello
chasm:(master)~/junk$ git-serve
Initialized empty Git repository in /home/gizbot/git/junk/
Counting objects: 3, done.
Writing objects: 100% (3/3), 217 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To dream:git/junk
* [new branch] master -> master
Set up the repository on dream in git/junk. Please double check your .git/config file:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = dream:git/junk
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
chasm:(master)~/junk$ echo "Hi" > hello; git commit -a -m "Hi."
[master dbdcb0a] Hi.
1 files changed, 1 insertions(+), 1 deletions(-)
chasm:(master)~/junk$ git push
Counting objects: 5, done.
Writing objects: 100% (3/3), 239 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To dream:git/junk
bb04a32..dbdcb0a master -> master
chasm:(master)~/junk$ git-serve
Current directory not a repository (no .git) or name taken at dream:git/junk
chasm:(master)~/junk$
April 30th, 2010 — Uncategorized
ANDROID! ANDROID! ANDROID! Only $3,000!
$3000? Read on.
It’s past time for a new phone, and like many overly technical people, I want the latest. I want the glitzy glass shard of crystallized dreams promising the future will come to me before I become an old guy cornering the weak and slow to tell war stories of the ancient bytes.
Shopping for shiny is expensive. Some future serfs exclaim “It’s only $200! And after rebate that’s only $100! Me want toy! Me want toy!” Visa predatory lending waits for those with slathering disregard for the Rules of Acquisition. Look for them being lemmings at Walmart or at the slave marts of dystopia.
The small ‘clink-clink’ of $200 gets lost in the real cacophony of fees, voice plans, and the nickel-and-dime confidence game that is the soul of American cellular phone carriers. The bling I have been eyeing today is the Droid Incredible. It’s shiny, new, and released just yesterday. It’s only $200! Right?
Bzzztt!! FAIL! Bankers eat your lunch! Out the door the phone has a price of $200 plus something called an ‘activation fee’ left over from the early land line days when some schmo with needle nose pliers and a beer belly had to dig into the wiring closet to put magic smoke into your wires. Today that fee is for what technical people call “adding a record to a database”. Oh, and you must get a hands-free device in California: it’s the law even though you are still driving as a drunk when you argue on the cell phone. Oh, and add on tax! The state gets its cut since taxing commercial land wouldn’t be fair.
Out the door:
$300 = $200 (shiny toy) + $35 (more shiny toy price but called ‘activation’) + $40 (car charger and hands-free) + $25 sales tax.
You might think, “Not too bad. I won’t balk on the shopper’s mound and leave the store. I’ll pay. It’s more than I thought, but it’s shiny!”. Bzzzt. Plan time.
Let’s start with voice minutes. Minutes? Think in hours! If you talk 1/2 hour a day you probably talk need a 15 hour voice plan, even with other ‘perks’ like free calls after 9 p.m. at night. You might need more: Verizon got caught at least once moving minutes around to push up the bill or other ‘extras‘. Also, figure in a lot of time to deal with the clunky, ‘designed like 1980′ voice mail system. If you talk too long on your 15 hour plan (900 minutes), you pay another $24 per hour.
Next, pay for data separately. What? Yes! You need a unlimited data plan for the other half of your phone. And it won’t help you if you go overseas where a megabyte page from Facebook will cost $20 on the pay-per-use, default plan. Horror stories abound about multi-thousand dollar bills: leave your phone at home like the third world telecommunications citizen you’ve become. And pay extra for the voicemail because all that advanced technology. And then there are ‘fees’ which like to sound like taxes but aren’t. These are just extra costs tacked on to your plans, but they won’t tell you how much in advance and might want more later. Figure about 20% of your bill plus another $1/month for fees. I’m guessing because they aren’t talking.
So monthly:
$113 = $60 (voice, 15 hours) + $30 (data) + $3 (voice mail) + $20 (additional ‘administrative’ fees)
Add another $20 (+$4 fees) per month if you text a lot and $15 (+$3 fees) if you use MS Exchange for email.
That contract you sign on the way out the door:
$3,012!
Yep. $300 for the phone and another $2,712 in monthly fees. Or more.
Don’t forget to value your time. Verizon, like many phone companies, changes the contract during the span of the contract. Those ‘Additional Verizon Fees’ change a whim. Some fees get charged for service not provided; until you hunt down good customer support. Internet message boards are thick with advice on how to hunt down good customer support to fix the billing problems, and it takes more time than just calling for customer support. In summary, expect to expend some effort in handling your Verizon bill. Picking a number from a wag hat, figure 10% in strange fees and half an hour a month on average to read and dispute the bill. I’ll leave those out of the following calculations: I’m OK with fuzzy numbers, but those last two are pure guess work.
So, a phone for $3,012 over the next two year, ignoring ‘gotchas’ and your time arguing. What’s that come out to?
$3,012 two year contract = $1,506 per year = $125 per month = $4.15 per day or $6 per workday.
I can understand $4.15 per day, every day. That’s lunch out three days a week. I can understand $125 per month. That’s buying thirty boxes of crayons for 12 classrooms each month, or a cheap lap top every four months. I can even understand $1,500 per year: that’s a conference or small vacation.
It might be worth it, it might not. That depends on you.
What else is there? Are you just screwed because there are no options? Can you get off the contract treadmill?
I looked at “Prepaid” options. Where prepaid used to be domain of “too poor for a phone” rates, it has become a real alternative. I work more on email now, and handle only a few calls a day when not next to a landline. I am excited about pushing my phone off to Teleku or Twilio so that I can hand out my phone number freely, send anyone I don’t know to a voicemail that sends email, forward some calls to my current landline, and have the computer use random, inventive diatribes to swear when telemarketers call. I’ll write scripts for it later and tell you how it went. What’s it cost?
I went to Slickdeals and searched for the latest deal. I bought a Nokia brick for now: a boring
phone that I don’t even know the name for. It cost me $20 for the phone and the first two hours of
airtime. Bing might even send me $7 back for the purchase. Some day. I put down $25 with
Teleku for the first six hours of forwarding and messages. So, the prepay comes out to:
$38 = $20 (phone, shipping, taxes, 2 hours of talk) + $25 (Teleku) – $7 Bing cashback
or
$38 for three months = $12 per month = $0 per day. Really, it rounds to zero.
So, I ordered the brick. I’ll try it as an experiment. I get to play with the Teleku interface and interactive voice response scripting. I still learn basic Android development off the emulators. I don’t need the handset for digging through tutorials, scanning documentation, and figuring out which of the usual choices the Android architecture chose. I don’t even need a phone for getting the software up to the ‘beta’ stage. Also, the cellular company is low risk: prepaid cellular horror stories appear to involve no more than loss of the prepaid minutes. And I can still make geek cred from IVR and Android development.
For me, this is a real alternative. If I’m wrong, it cost me the same as a week and a half with the Android handset.
Make your choices based on the real costs. Think in terms of daily, monthly, and yearly total dollars.
http://teleku.com/
December 22nd, 2009 — Uncategorized
“chown“, “chgrp“, “ln“, and “chmod“, behave oddly on fat-32, vfat, and ntfs file systems. The “Operation not permitted” message may mean “This type of filesystem does not support that operation”.
Here’s the example: I want to create a file and own the file. I can’t seem to do it.
Step 1: Confusion! I don’t own the files I create!
chasm@chasm-blue-laptop:/big$ whoami
chasm
chasm@chasm-blue-laptop:/big$ date > today
chasm@chasm-blue-laptop:/big$ ls -la today
-rwxrwx— 1 root plugdev 29 2009-12-22 15:15 today
The created file, /big/today, is owned by user root, and group plugdev. I can create, modify, and delete the file but I can’t seem to own it. I had not heard of the plugdev group and Google is not helpful. The plugdev group manages which users are allowed to use hot pluggable media and FAT-32 media. Use ‘grep plugdev /etc/group’ to see who is in the plugdev group.
Step 2: Failures and Bad Error Messages.
Even as root, I cannot change the owner, root, or permissions.
chasm@chasm-blue-laptop:/big$ ls -la today
-rwxrwx— 1 root plugdev 29 2009-12-22 15:27 today
chasm@chasm-blue-laptop:/big$ sudo chown chasm today
chown: changing ownership of `today’: Operation not permitted
chasm@chasm-blue-laptop:/big$ sudo chgrp chasm today
chgrp: changing group of `today’: Operation not permitted
chasm@chasm-blue-laptop:/big$ sudo chmod -x today
chasm@chasm-blue-laptop:/big$ ls -la today
-rwxrwx— 1 root plugdev 29 2009-12-22 15:27 today
chasm@chasm-blue-laptop:/big$ sudo ln -s today anotherday
ln: creating symbolic link `anotherday’: Operation not permitted
Note the problems with error messages: “Operation not permitted” is not about user privileges, and chmod fails silently. In this case, “Operation not permitted” means “The vffat filesystem does not support that operation”.
Step 3: Enlightenment
The problem is that FAT-32 file systems do not have permissions, owners, and groups per se. The entire file system is given one set of permissions at mount time, specified in the file /etc/fstab. Let’s change it.
chasm@chasm-blue-laptop:/big$ grep “/big” /etc/fstab
# /big was on /dev/sda6 during installation
UUID=C14C-CE25 /big vfat utf8,umask=007,gid=46 0 1
chasm@chasm-blue-laptop:/big$ sudo vi -u NONE /etc/fstab
chasm@chasm-blue-laptop:/big$ grep “/big” /etc/fstab
# /big was on /dev/sda6 during installation
UUID=C14C-CE25 /big vfat utf8,umask=007,uid=1000,gid=1000 0 1
I made this change using vi -u NONE to preserve tabs. Before the change all files in the /big file system were owned by the uid of 0 (root) in the gid of 46 (plugdev). After the change, all files will now belong to uid and gid. Here’s the quick test of remounting the filesystem with the new permissions.
chasm@chasm-blue-laptop:/big$ cd ..
chasm@chasm-blue-laptop:/$ sudo umount /big
chasm@chasm-blue-laptop:/$ sudo mount /big
chasm@chasm-blue-laptop:/$ ls -l /big/today
-rwxrwx— 1 chasm chasm 29 2009-12-22 15:27 /big/today
The only way to change a permission is to change permissions for the entire file system in /etc/fstab. Also, the file system supports neither symbolic links nor hard links.
June 17th, 2009 — Politics
Dear Honorable Representative Honda:
Silicon Valley needs an absolute immunity that limits damages for auto-driving cars to $10 million per death or injury.
Silicon Valley is looking for another trillion dollars worth of growth to fuel. One great idea is limited by the absence of barely-controversial legal framework. You could provide this framework, enable use to get back to work, make money, and make everyone happy.
Everyone includes the seed level start-ups based on Stanford’s historic win on the DARPA Grand Challenge auto-driving contest, the 40,000 Americans that die each year from accidents, and my six year old who is more danger from automobiles than any other source. The primary hold-ups are legal, not technical.
Good legislation would specify maximum damages, perhaps indexed to COLA. The maximum amount would need to include any payments for negligence, wrongful death, unsuitability, and fines among all possible parties from designers, software, manufacturers, and dealers. Having some maximum liability amount, any amount, means that companies can go build in liability and proceed. If the legislation only covered cars manufactured until 2030, that would be plenty.
One licensed driver in 5,000 currently dies from car accidents every year. If an American company reduces that number to one in 50,000, it should not be destroyed by the variability of the court system.
Please sponsor such a bill, which would likely be debated in your Appropriations/Commerce subcommittee.
Charles Merriam
August 15th, 2008 — Coding, Reviews, Web, Write-up
Some follow-ups, corrections, and expansions. Being correct takes effort.
First, someone very knowledgeable on the internals noted that I was sloppy with the terms ‘datastore‘, ‘GBase‘, ‘GoogleBase‘, ‘GQL‘, and ‘BigTable‘. Mea culpa. Datastore is the most generic term and the specific one for Google App Engine is referred to as the “App Engine datastore“. The App Engine datastore is accessed through GQL, a language reminiscent of SQL. The App Engine datastore is built on BigTable and exposes some of BigTable’s capabilities (see Wikipedia, a formal paper, or video documentation). GoogleBase is an independent Google product that is also built on BigTable. GBase is a guitar search engine and the naturally elided form of “GoogleBase” after saying it a hundred times. Whew! Terms.
Speaking of terms, the contract term dealing with indemnification in the Terms of Service:
13.1. You agree to hold harmless and indemnify Google, and its subsidiaries, affiliates, officers, agents, employees, advertisers, licensors, suppliers or partners, (collectively “Google and Partners”) from and against any third party claim arising from or in any way related to (a) your breach of the Terms, (b) your use of the Service, (c) your violation of applicable laws, rules or regulations in connection with the Service, or (d) your Content or your Application, including any liability or expense arising from all claims, losses, damages (actual and consequential), suits, judgments, litigation costs and attorneys’ fees, of every kind and nature. In such a case, Google will provide you with written notice of such claim, suit or action.
The annoying clause is “(b) your use of the Service”. Given how claims are written in patents, it is entirely likely that use of the API would be an actionable breach if the Google App Engine violated patents. Google could require indemnification by users of the API. For most people and smaller companies, the reputation of Google and pledges to “not be evil” should be sufficient.
Speaking of evil (note the clever transistion), the lazy index evaluation that makes the database look like “read committed” is discussed here.
Finally, high availability is hard, and “9′s” go faster than you remember.
90% (1-nine) is a downtime of 36.5 days per year.
99% (2-nines) is a downtime of 3.65 days per year.
99.9% (3-nines) is a downtime of 8.65 hours per year.
99.99% (4 nines) is a downtime of 52 minutes per year.
99.999% (5 nines) is a downtime of 5.2 minutes per year, or six seconds per week.
A claim of about 2-nines reliability is reasonable. Google App Engine was launched around four months ago in mid-April, so about a day of downtime is 2-nines. It was down on June 17 for some unreported number of hours, and was down again on June 19 and June 25. Add in little outages where various features broke, blocking PayPal, and other nits. There is a list that occasionally reports downtime, but no exact statistics are available. If there were no future outages, and you wanted to demonstrate four nines reliability, it would need to take years to overcome the existing outages.
Keep on working on it. I hope that Google App Engine will be more fun in the future.
August 15th, 2008 — Coding, Reviews, Write-up
[I gave this talk at the BayPiggies Meeting on August 14, 2008. The 'Newbie Nugget' talk ran about seven minutes and used only spoken words. This is my recollection of what I said.]
I drove here today. I got in my car, used the six speed manual transmission, steering wheel, and pedals. I had to know how to change lanes and the rules of the road. I needed to know traffic patterns, and directions from my house to Google. I got here.
It was the most dangerous thing I did today. Traffic accidents kill about 40,000 people a year in the U.S. alone. It’s the number one cause of death for everyone from age five to about my age where heart disease and cancer start catching up. We just take it for granted. That’s not the car I want.
I Want My Autodriving Car! I want to push a button on my cell phone, walk out the door a minute later, and hop into the open door of a car. It would take me where I want to go, take the best route given current traffic, and drop me in front of the door. It would never crash. It would just work. That’s what I want in a car.
Here’s what I want in an application engine. I want to write in one language. I want one set of tools. One naming convention. I want to be able to translate my thoughts into code cleanly. I want the application to be on the Internet and scale and to share that application with everyone through a url or something like the IPhone App Store. That’s what I want in an application server.
Google App Engine is not there yet. Google App Engine is a step along that path, and lets you see where application engines are headed. For the first time, you can see that installing and configuring MySQL on a server and then renting space in a rack for the server will someday sound the same as someone talking about pulling the engine in his car and changing out the rings in the driveway. I guess you could do that yourself, but why? You still need to work in the soup of languages: HTML, CSS, JavaScript, HTTP headers, Flash, Python, and more. You still need to coordinate your tools for each language: editor coloring, debugger, make system, test harness, code coverage, and documentation. It does us good to keep our eyes on the App Engine we want.
So, let’s talk about Google App Engine: what is does, how to write for it, where you would use it and not.
Google App Engine is fundamentally a deployment engine. After you write your application, it provides that application out on the Internet. It’s also very early technology. It sort of supports Django (‘jango’ for those who talk; ‘d-jango’ for those who read), but using the latest version runs up against its thousand file limit. Fully half of the seventy posts a day on the mailing list are about deployment quotas or looking for workarounds to deployment limits. You cannot run any long job that takes more than a few seconds. Still, it’s free.
Writing for Google App Engine is much like writing for any other application engine. You use the WSGI interface, which someone taught me is pronounced ‘whiskey’, that provides a mapping between the requested URLs and the classes to serve them. You write a class that has methods to respond to HTTP messages like get and put. Your codes spits out the HTML and whatever to respond. Sometimes you trigger urlfetch, from urllib, of your own application like remote procedure calls to avoid hitting computation time request limits. You store your data in the Google Base data store.
Google Base can be a problem. The Google Base datastore is not a relational database. It’s a great database for working data you collect from all over the web, like web pages or screen scraping, where you are working with massive amounts of data and some of it is always aging out. It should never be used for accounting. For example, you can’t just run a GBase query to update the total invoices for a month. You need to walk through all the records. If you update the date on an invoice and then retotal the invoices, you might get the wrong answer. GBase doesn’t guarantee the invoices index is immediately updated. It would probably work, but if you were to try running tests to see how often it fails you’d use up your quota and be locked out for a few days.
So where is Google App Engine the right choice? First, it’s free. It’s a good way of learning how to write for application servers. There are some good tutorials and videos and off you go. If your application needs a lot of bandwidth downloading from elsewhere on the internet, it’s probably a good choice. So if you want to try out an idea that’s not for making money, go for it.
Where is Google App Engine the wrong choice? If you are trying to make money, it’s right out. First, the license includes clauses that require you to indemnify Google if the API infringes patents. A Fortune 500 company won’t let you agree to that. Second, its reliability wants to get up to five nine’s (.99999) but is hovering between one and two nines. Third, it’s really early tech. You can watch lots of bugs get filed and occasionally fixed, but they are in the stage of getting it feature complete first.
In conclusion, I want an auto-driving car and I want my great application engine. Google App Engine is like getting a taxi. A taxi does the driving, but I still need to know directions and road conditions, and I still get into car accidents. With Google App Engine, I still need to know the whole stack of languages, my site still gets hacked, and it still goes down a lot. But you can see the future in Google App Engine, and it may turn into something great.
[Clarifications and follow-ups for this article got a bit long. I added some expansions on this blog post.]
July 28th, 2008 — Uncategorized
For those few brave souls working on KDE 4, this is my list of bugs I noticed in the first couple hours. Some may be viewed as belonging to other subsystems. This is installing KDE 4.1, 32 bit, on a new T-6836 laptop.
- On live CD, font on “read me” came up as unreadable and clipped.
- The whole “add widgets” system is difficult; I keep wanting to add widgets to my task bar.
- Double clicking on a downloaded debian package brings up Ark but without the package loaded. Ark doesn’t appear to handle this file type.
- Hey! Where’s my alt-space quick launch (Katapult) or a replacement.
- Where’s my easy “look for more widgets to install” thingee?
- During install on partitioning disks, the progress bar hangs at 0% for about five or ten minutes.
- My traditional bar across the bottom disappeared and I don’t know where it went. Sometimes KDE seems to fail to bring up any interprocess communication.
- Once I moved the app launcher to the right hand, it made my menus funky, and I don’t know how to make it go back. I eventually blew away my .kde* directories
- Why do I have a .kde3 directory when running kde4?
- Tons and tons of warnings and errors in the dbus backtrack.
- Crashing Konquerer on GMail. Why KDE has its own browser is beyond my keen.
- Grub should initialize with better names. Not just “Generic Linux…” and “Windows Longhorn…”. Also, there are two Windows entries, one of which should be labelled recovery.
- Default width on “Add Widgets” box is way too narrow.
- In “Add Widgets”, “Pager”, “System Tray” and “Task Manager” have too generic icons.
- Can’t be sure or prove it, but “All Widgets” seems to not have all widgets the first time.
- Power management, by default, ran until out of battery and turned off.
- Appears not to save settings until successful shutdown of window manager.
- When I click on the “Leave” icon, choose restart, I get another level of menus to try to restart again.
- Network manager crashed at least once or twice. No clear way to make it start again.
- No ‘small icons’ for a quick launch bar.
After a certain level of bugginess, it makes no sense to report bugs unless one is also submitting patches.
July 25th, 2008 — Coding, Reviews, Web, Write-up
80% of effects come from 20% of causes
— Pareto Principle by Vilfredo Frederico Damaso Pareto, 1906
90% of Everything is Crud
– Sturgeon’s Law by Theodore Sturgeon, 1956
100% of Everything is Crud
– Linear extrapolation of above, 2006.
There seems to have been a natural tendency for us to look at past as some magical time when quality mattered. Really, only the pure quality of finished work survived. We forget the uncountable steps towards quality.
In the world of desktop environments, the journey towards quality continues. KDE 4.1 makes a step, following trends, and aiming to be The One Last and True Windowing System.
Quality Steps and Missteps
I installed Kubuntu with KDE 4 on my laptop, and am using it to write this post. That it is written at all shows a minunum level of quality. That the post starts with these quotes shows a maximum level.
I find immediate problems when installing. The very first action, the “Read Me” during the LiveCD boot,
comes up in a clipped and illegible font. During partitioning the disks, the progress bar hangs at 0% for ten minutes. The task bar lacks resizing and basic functionality. The quick launcher, Katapult, disappeared. A new program launcher experiment falls flat with some buttons activating by click and other by hovering the mouse. Konquer still crashes. I discover new bugs a few times per hour. These are the the nits and bugs of a new system.
The subtle problems are the problems repeated from previous years: the LILO boot system that unhelpfully refers to Vista as “longhorn” and Kubuntu as “generic Ubuntu core”; the cobbleware of screen layout that has fonts too big for buttons, text too wide for dialogs, and odd alignments; the usual flakiness with power and wireless management. These problems persist for ages from expectation, difficulty, or blindness.
So quality is a step downward while the easy bugs are fixed. Some nice features, like FileLight 
are a definite step up that I expect every other distribution to copy soon. KDE did buck the trend in releasing a quality downgrade.
Trends in Window Managers
KDE 4 follows the collective wisdom of other software competitors including GNOME, Sugar, Microsoft’s Windows line, and Apple’s OS X line. It tries to be different just like everyone else. It adds new functionality in pieces and parts. The hodgepodge of bundling, or smush, that make up windowing systems includes GUI and interface candy, applications, and APIs.
Smush is not pejorative. Open source swaps in and out competing components and the windowing system selects components under its seal of approval and delinates APIs outside its control. Quality for each component is involved at several layers. When the power management on my laptop fails to hibernate before powering off, I could file a bug with KDE, Ubuntu (link to shuttleworth), Debian, the Linux ACPI mailing list, hardware discovery, or just fix it myself. When searching for a workaround, it could exist anywhere.
KDE is following the trend towards aggressively cross platform deployment. By using Qt 4 as it’s underlying graphics engine, KDE hopes to deploy on desktops (Linux, MS Windows, and OS/X), cellular phones, and some embedded devices. It is currently hampered by Qt 4 having no LGPL or BSD license, requiring a special licensing cycle to deploy any commercial application. The previous Qt 4 copyright holder, TrollTech needed this revenue to continue operations. The new holder, Nokia, may free the code in order to encourage wider adoption and easier developer migration to its cellular phones.
KDE also follows the practice of wrapping more and more functionality into API layer plug-ins. Rather than commit to a scripting language, Kross wraps or interfaces to Python, Ruby and JavaScript. Rather than commit to a multimedia engine, Phonon creates one more layer of indirection for a common interface to GStreamer, QuickTime, DirectShow, and others. The new release switches many of the wrappers so now it is Phonon (multimedia), Solid (device integration), Plasma (a new desktop), Kross (scripting), DXS (application data updates), Decibel (human communications), and D-BUS replacing DCOP (application messaging). It is unclear if “one more layer of indirection” will be the correct solution in the long run.
In the long run, of course, KDE hopes to birth “The One Last and True Windowing System.”
The One Last and True Windowing System
Results 1 – 10 of about 1,040
– Google search for “One API to Rule Them All”
Windowing systems race towards the goals of full functionality, sweet abstractions, and wide deployment with the winner creating a work that will last decades. Each release brings new experiments and implements growing standards. Implementations trump ideas. Differing implementations get abstracted and merged. Engineers have always raced towards sweet solutions.
Software does get finished. We still use the C programming language after more than a third of a century. The syntax, style, and assumptions are passed to new languages such as C++, Python and Ruby. Other contenders failed. Hardware architectures now handle pointer indirections, sequential arrays, and null terminated strings. C goes through occasional updates and forks, but it endures. Also enduring are the most of the Internet stack including TCP/IP, DNS/Bind, and packet switching; HTTP protocols, SQL, and many more. These become the common parts upon which we solve new problems. Many hope to finish writing the desktop software.
FreeDesktop.org gently pushes towards standardization by facilitating discussion. It speeds the process of making compatible, then integrating, then merging competitng development that has become similar. It’s influence on KDE is unmistakable.
So, will KDE give birth to the “One Last and True Windowing System” that lasts for decades?
Conclusions
KDE took a significant risk. It’s adoption of Qt 4, dropping of DCOP, and making so many changes significantly hurt its quality. On the other hand, it might provide a new level of functionality to catapult into the top three windowing systems. Time will tell. For people just wanting a desktop to work, stay away for six months. Continue reading →
July 23rd, 2008 — Uncategorized
I went out and bought a new laptop, having succesfully proven that driving over a laptop is not a good idea.
First, I watched SlickDeals for a reasonable, cheap system. I’ve found that laptops have a short obsolescence period, and buying near the bottom end is best. Second, I went to Best Buy and picked it up. Best Buy has a less than stellar reputation, so I double-checked the factory seals.
And the system had a bad wireless. DOA. Some hours on Gateway’s chat trying to install drivers for a broken subsystem. They gave me an RMA number; Best Buy has a less than stellar reputation.
The next morning, I went back to Best Buy. Ten minutes for them to poke and prod and I had a new system on the way out. Sometimes the reputation is undeserved.
Boot up Windows; download Firefox; download Kubuntu; burn CD; install and go.
Life is better again.
