This new theme was chosen to both match Software Federation’s new Web 2.0-ish look and feel, as well as for me to have the opportunity to play around with magazine-ish look-and-feels in anticipation of an upcoming product we have been planning to build for some time now.

The theme we chose is the Morning After theme. A review of this theme can also be found here.

This theme has a lot of cool features, like featured posts and asides, and lots of functionality which we have not yet begone to explore (we just updated Wordpress and installed the theme late yesterday). So far, we have been mostly replacing floats with divs and tables so that when we use font sizes large enough for people who are on the high side of 40, the layout is preserved.

Otherwise, the PHP seems very well designed and my overall impression at this point is very favorable. We hope that your impression is likewise - but if not, please let us know!

Here is what I did. Hopefully it’ll work for you too.

In my Subversion installation directory, ON MY WINDOWS BOX (don’t you go wasting several hours on this, too, I wasted enough for the whole kit-and-kaboodle of us on this one) I added a conf subdirectory.

in there I added a file called config. The contents of this file is at the end of this blog post. You can see examples of this file all over the net.

Then, in my batch files I created to do the import and checkin and add I add, in my case:

–config-dir C:\runtime\svn-win32-1.4.6\conf

Of course, in your case, you would replace ‘C:runtime\ svn-win32-1.4.6′ with the path to YOUR subversion installation.

For example my checkin.bat looks like:

svn commit -m “Checking In” –config-dir C:\runtime\svn-win32-1.4.6\conf –username me –password my_password

(actually, I have another line in this file that calls a script to automatically add all new files that have been created since the last checkin. Subversion can’t do this itself, for some reason. They don’t call it source code management SCuM without a good reason).

OK, here is the file. What this says is to set end-of-line properties to linefeed for files with extensions that are likely to be text files.

The key lines are to enable the property feature.
enable-auto-props = yes

and the lines at the end of the file that specify what to do about files with various extensions. Specifically, in our case:

*.rb = svn:eol-style=LF

——————————————————————————————————————————–

###
### The commented-out examples below are intended to demonstrate
### how to use this file.

### Section for authentication and authorization customizations.
[auth]
### Set store-passwords to ‘no’ to avoid storing passwords in the
### auth/ area of your config directory. It defaults to ‘yes’.
### Note that this option only prevents saving of *new* passwords;
### it doesn’t invalidate existing passwords. (To do that, remove
### the cache files by hand as described in the Subversion book.)
# store-passwords = no
### Set store-auth-creds to ‘no’ to avoid storing any subversion
### credentials in the auth/ area of your config directory.
### It defaults to ‘yes’. Note that this option only prevents
### saving of *new* credentials; it doesn’t invalidate existing
### caches. (To do that, remove the cache files by hand.)
# store-auth-creds = no

### Section for configuring external helper applications.
[helpers]
### Set editor to the command used to invoke your text editor.
### This will override the environment variables that Subversion
### examines by default to find this information ($EDITOR,
### et al).
# editor-cmd = editor (vi, emacs, notepad, etc.)
### Set diff-cmd to the absolute path of your ‘diff’ program.
### This will override the compile-time default, which is to use
### Subversion’s internal diff implementation.
# diff-cmd = diff_program (diff, gdiff, etc.)
### Set diff3-cmd to the absolute path of your ‘diff3′ program.
### This will override the compile-time default, which is to use
### Subversion’s internal diff3 implementation.
# diff3-cmd = diff3_program (diff3, gdiff3, etc.)
### Set diff3-has-program-arg to ‘true’ or ‘yes’ if your ‘diff3′
### program accepts the ‘–diff-program’ option.
# diff3-has-program-arg = [true | false]

### Section for configuring tunnel agents.
[tunnels]
### Configure svn protocol tunnel schemes here. By default, only
### the ’ssh’ scheme is defined. You can define other schemes to
### be used with ’svn+scheme://hostname/path’ URLs. A scheme
### definition is simply a command, optionally prefixed by an
### environment variable name which can override the command if it
### is defined. The command (or environment variable) may contain
### arguments, using standard shell quoting for arguments with
### spaces. The command will be invoked as:
### svnserve -t
### (If the URL includes a username, then the hostname will be
### passed to the tunnel agent as @.) If the
### built-in ssh scheme were not predefined, it could be defined
### as:
# ssh = $SVN_SSH ssh
### If you wanted to define a new ‘rsh’ scheme, to be used with
### ’svn+rsh:’ URLs, you could do so as follows:
# rsh = rsh
### Or, if you wanted to specify a full path and arguments:
# rsh = /path/to/rsh -l myusername
### On Windows, if you are specifying a full path to a command,
### use a forward slash (/) or a paired backslash (\\) as the
### path separator. A single backslash will be treated as an
### escape for the following character.

### Section for configuring miscelleneous Subversion options.
[miscellany]
### Set global-ignores to a set of whitespace-delimited globs
### which Subversion will ignore in its ’status’ output, and
### while importing or adding files and directories.
# global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store
### Set log-encoding to the default encoding for log messages
# log-encoding = latin1
### Set use-commit-times to make checkout/update/switch/revert
### put last-committed timestamps on every file touched.
# use-commit-times = yes
### Set no-unlock to prevent ’svn commit’ from automatically
### releasing locks on files.
# no-unlock = yes
### Set enable-auto-props to ‘yes’ to enable automatic properties
### for ’svn add’ and ’svn import’, it defaults to ‘no’.
### Automatic properties are defined in the section ‘auto-props’.
enable-auto-props = yes

### Section for configuring automatic properties.
[auto-props]
### The format of the entries is:
### file-name-pattern = propname[=value][;propname[=value]…]
### The file-name-pattern can contain wildcards (such as ‘*’ and
### ‘?’). All entries which match will be applied to the file.
### Note that auto-props functionality must be enabled, which
### is typically done by setting the ‘enable-auto-props’ option.
*.c = svn:eol-style=LF
*.cpp = svn:eol-style=LF
*.h = svn:eol-style=LF
*.dsp = svn:eol-style=CRLF
*.dsw = svn:eol-style=CRLF
*.sh = svn:eol-style=LF;svn:executable
*.txt = svn:eol-style=LF
*.png = svn:mime-type=image/png
*.jpg = svn:mime-type=image/jpeg
*.gif = svn:mime-type=image/gif
Makefile = svn:eol-style=LF
*.rhtml = svn:eol-style=LF
*.fcgi = svn:eol-style=LF
*.cgi = svn:eol-style=LF
*.rb = svn:eol-style=LF
*.txt = svn:eol-style=LF
*.yml = svn:eol-style=LF
*.html = svn:eol-style=LF

First off, the Joyent wiki documentation is kind of confusing. You got textdrive the product and textdrive the server, shared hosting, shared accelerators, connectors, plain accelerators… product names, service names and domain names are all overloaded. And, coming in from Google, there are no markings on the pages to tell in which section they are part of, and their forums are like this too.

So all this is to say, please excuse me and do not laugh to hard when you read that, at my registrar (GoDaddy), to set up my DNS:
I first tried

dns1.textdrive.com
dns2.textdrive.com
dns3.textdrive.com
dns4.textdrive.com

I then tried

dns1.joyentdns.com
dns2.joyentdns.com
dns3.joyentdns.com
dns4.joyentdns.com

Finally, I figured out that this was for one of their other services, so, at GoDaddy the trick was to:

First configure your domain so that it says it is to be hosted at GoDaddy It isn’t really going to be, Well, the name server is, but not the pages. Anyway, another overloading of terms here.

Then use Total DNS Control Panel to point (in the Default DNS zone) the host at your IP address over at Joyent. Started working in about an hour or so.

Anyway, followed the directions in http://wiki.joyent.com/accelerators:absolute_beginners_guide and http://wiki.joyent.com/accelerators:deploying_rails_apps

Set up Subversion, SVN client on Windows box, SVN server on the Joyent server. The SVN server is already in place, but when adding user to access SVN, well, there are config files in ~/etc/subversion and in ~/.svn/subversion? Anyway there are two, and well, here is the thing. The Subversion user must be able to have access to subversion, SSH to be able to log in automatically from the client, and to add things to your deployment directory.
One of the mistakes I made was to create a special SVNUser, which I then backed out this and had to modify all the config files blah blah blah pain pain pain.

Then, a ‘feature’ of su on Solaris is apparently that when you su Another_User ~ (i.e. tilde) still points to the home directory of the user you logged in over SSH as. so all those config files I set up? They were for admin, not the SVN user. Doh!

And then, the documentation says that the URL for the SVN repository is http://my_domain_name.com/svn/repos. Well it took me forever to figure out that repos was supposed to be the name of the repository, which was something like svnreposository in my case.

Yeah, Yeah, we all laugh about it NOW. But these things took hours to figure out. OK, you can stop laughing now.

Then, related to the above ’su’ anomaly, make sure when you checkout of SVN, to ‘prime’ it for the initial import process, that you do it as the user who will be doing the import in. And you can’t su to them you have to log in as them.
svn export http://my_domain_name/svn/my_repostiroy_name/trunk /home/somewhere_temporary/tmp

Next, how to get rid of those nasty ^M ’s all over the freakin place.

And, to get different blog software, as this version of Wordpress has a NASTY text editor that is slow and weird and jumps around and is more or less useless.

…the default ARmailer template feature doesn’t work the way it is documented.

At least if you want to use the features where you just have to put the email templates in a directory and the mailer generates and sends a multi-part email for ya.

Why?

Because this:

ActionMailer::Base.template_root = “mailer/templates”

does not work. Why, you might ask?

Because, in ActionMailer::Base, template_root is defined as:

class_inheritable_accessor :template_root

So assigning it a value like it was a class variable, doesn’t work because it is an instance variable.

What I did was to copy exception_notifier’s approach and override the accessor method in our notifier.rb model class:

def template_root
‘app/views’
end

Now, our notifier model class [subclassing ActionMailer::ARMailer, used to be ActionMailer::Base]
can use templates, like:

new_photo_notification.text.plain.rhtml
new_photo_notification.text.html.rhtml

which we put in a directory under apps/views/notifier

 The main link for information is: http://code.google.com/apis/checkout/

at that link the main page is: http://code.google.com/apis/checkout/developer/index.html

SETTING UP SANDBOX ACCOUNTSÂ

One of the first things ya gotta do is setup three google accounts - one real and one sandbox seller (merchant account) and one sandbox buyer. In order to differentiate the sand box accounts from each other and from your real one you need to use different email addresses when you set them up. Yeah, so that means three email addresses are required, since that is what you use to log in to these accounts. I used real email addresses - and don’t know if fake ones will work just as well. Your page for your real account will have a link on it to your sandbox account(s) login.

 The pertinent paragraph in the docs is:Â

“You need to create two test accounts in the Sandbox. One of these accounts will function as a customer account and the other will function as your merchant account. Please note that Google Checkout does not allow a single account to function as both the customer and the merchant for the same transaction. In addition, the links in the previous sentence point to different signup URLs, and you will be asked for different information to create these two accounts.”

This link to create the sandbox customer account did not work for me, perhaps because I created the sandbox merchant account first [long story, suffice it to say that I incorrectly used my ‘real’ email address to create my first sandbox account]. A link that DID work for me is: http://sandbox.google.com/checkout/buy

SETTING UP A CART and HANDING THE USER OVER TO THEIR GOOGLE ACCOUNT SO THAT THEY CAN MAKE PAYMENT

 Here is the code as it stands now. Seems to me that taking their sample code and modifying it, [i.e. the MerchantConstants file and the event handlers] which is what a lot of people do, is not the best idea. What if google changes things later? Ya want to keep rewriting this stuff? Who wants to spend the time to setup and incorporate the building of this code into their app? Anyway, the following code uses what they call their example code in a minimal fashion, and will probably not use it at all next revision.

I chose to use the Java 1.4 version, since I use Jikes [a very fast compiler]Â and that is stuck at 1.4 [looks like we will have to abandon Jikes unless someone steps in and updates it real soon now]. But the example code, all that I’ve been able to find, is in the jsp fiels in the top level directory of the jdk 1.5 version WAR file that google has on their downloads page: http://code.google.com/apis/checkout/samplecode.html

The other part of this code, the asynchronous callback handler that lets goggle send us messages to let us know how the checkout process went, will be posted at a future date (aka after it works).

We are using resin-pro 3.x and had a little bit of a hard time getting it to see all of the classes this code references in the jaxb libraries that the google checkout sample code uses. One thing that I did to make sure Resin found some of the classes at runtime was to rename xsdlib.jar to axsdlib.jar, so that it would be loaded before libs that reference it. Shades of LD_LIBRARY_PATH…

Part II will be forthcoming after CES sometime… as will more comments here… Strings is our class here that manages lists of class String. EVerything else is a google checkout class provided by their example libraries. So, anyway, here is an example of how to create a cart and send it, and the user, off to Goggle after polling it for an address to send them to.

  Â
import javax.xml.bind.JAXBException;
import com.sun.msv.datatype.xsd.DoubleType;

import com.google.checkout.sample.util.StringUtil;
import com.google.checkout.sample.protocol.CheckoutCartBuilder;

import com.google.checkout.schema._2.impl.AnyTypeImpl;
import com.google.checkout.schema._2.USStateArea;
import com.google.checkout.schema._2.Item;
import com.google.checkout.schema._2.ShoppingCart;
import com.google.checkout.schema._2.ShippingRestrictions;
import com.google.checkout.schema._2.DefaultTaxTable;
import com.google.checkout.schema._2.DefaultTaxRule;
import com.google.checkout.schema._2.MerchantCheckoutFlowSupport;
import com.google.checkout.schema._2.CheckoutRedirect;
import com.google.checkout.sample.crypto.CryptUtil;
//import com.google.checkout.sample.MerchantConstants;

import org.w3c.dom.Document;

import org.xml.sax.InputSource;
import javax.net.ssl.HttpsURLConnection;

/**----------------------------------------------------------------------------------------------
 * This class
 *
 * @author      Michael L. Davis
 *----------------------------------------------------------------------------------------------*/
public class NzGoogleCheckoutOperations implements NziBillingMethodWorkflow
	{
	private static	final String	sandboxMerchantId	= "xxxxxxxxxxxxxxxx";
	private static	final String	sandboxMerchantKey	= "xxxxxxxxxxxxxxxxxxxxxxx";
	private static	final String	sandboxRequestUrl	= "https://sandbox.google.com/cws/v2/Merchant/" + sandboxMerchantId + "/request";
	private static 	final String	sandboxCheckoutButtonUrl= "http://sandbox.google.com/buttons/checkout.gif?merchant_id=" + sandboxMerchantId;		 // "http://sandbox.google.com/checkout/" after 1/3/07
	private static	final String	merchantId		= "xxxxxxxxxxxxxxxxxxxxx";
	private static	final String	merchantKey		= "xxxxxxxxxxxxxxxxxxxxxxxx";
	private static	final String	requestUrl		= "https://checkout.google.com/cws/v2/Merchant/" + merchantId + "/request";
	private static 	final String	checkoutButtonUrl	= "http://checkout.google.com/buttons/checkout.gif?merchant_id=" + merchantId;

	public				NzGoogleCheckoutOperations()
		{
		}

	public static	String		getMerchantID()
		{
		if (Utility.toBoolean(NzConfigurationResources.get(NziConstants.NZ_GOOGLE_CHECKOUT_USING_SANDBOX)))
			{
			return(sandboxMerchantId);
			}
		return(merchantId);
		}
	private static	String		getMerchantKey()
		{
		if (Utility.toBoolean(NzConfigurationResources.get(NziConstants.NZ_GOOGLE_CHECKOUT_USING_SANDBOX)))
			{
			return(sandboxMerchantKey);
			}
		return(merchantKey);
		}
	private static	String		getRequestUrl()
		{
		if (Utility.toBoolean(NzConfigurationResources.get(NziConstants.NZ_GOOGLE_CHECKOUT_USING_SANDBOX)))
			{
			return(sandboxRequestUrl);
			}
		return(requestUrl);
		}
	public static	String		getCheckoutButtonUrl()
		{
		if (Utility.toBoolean(NzConfigurationResources.get(NziConstants.NZ_GOOGLE_CHECKOUT_USING_SANDBOX)))
			{
			return(sandboxCheckoutButtonUrl);
			}
		return(checkoutButtonUrl);
		}
	public static 	String 		getHttpAuth()
		{
		if (Utility.toBoolean(NzConfigurationResources.get(NziConstants.NZ_GOOGLE_CHECKOUT_USING_SANDBOX)))
			{
			String combinedKey = sandboxMerchantId + ":" + sandboxMerchantKey;
			return(CryptUtil.base64Encode(combinedKey));
			}
		String combinedKey = merchantId + ":" + merchantKey;
		return(CryptUtil.base64Encode(combinedKey));
		}

	public 		boolean		billCustomer(
						String accountId,
						String pendindOrderId,
						Strings orderItemIds,
						String cost,
						String taxAmount,
						String discount,
						String totalAmount,
						Strings itemizedCosts,
						Strings itemizedCostsDescriptions,
						Strings itemizedDiscountIds,
						Strings itemizedDiscounts,
						Strings itemizedDiscountsDescriptions,
						String customerReference,
						String generalDescription,
						Strings errors,
						HttpServletRequest request, HttpServletResponse response ) throws ServletException, IOException
		{

		// Google
		String[] signature = new String[1];
		String cart = null;

		try	{
			cart = buildEncodedCart(
						accountId,
						pendindOrderId,
						orderItemIds,
						cost,
						taxAmount + "",
						discount,
						totalAmount,
						itemizedCosts,
						itemizedCostsDescriptions,
						itemizedDiscountIds,
						itemizedDiscounts,
						itemizedDiscountsDescriptions,
						customerReference);
			}
		catch (Throwable t)
			{
			NzLog.logException("Unable to build google cart for account: " + accountId, t);
			}

		try	{
			URL url = new URL(getRequestUrl()); 

			HttpsURLConnection conn = (HttpsURLConnection) url.openConnection(); 

			conn.setDoOutput(true);
			conn.setDoInput(true);
			conn.setRequestMethod("POST");
			conn.setRequestProperty("Authorization","Basic " + getHttpAuth());
			conn.setRequestProperty("Content-Type","application/xml");
                	conn.setRequestProperty("Accept","application/xml");
			conn.setRequestProperty("Host", conn.getURL().getHost());
			conn.setUseCaches (false);
			conn.setInstanceFollowRedirects(true);
			conn.connect(); 

			OutputStreamWriter wr = new OutputStreamWriter(conn.getOutputStream());
			wr.write(cart);
			wr.flush();
			//wr.close(); 

			CheckoutRedirect redirect = null;
			try	{
				String responseCode = "" + conn.getResponseCode();
				String responseMessage = "" + conn.getResponseMessage();

				//Get the response
				InputSource source = new InputSource(conn.getInputStream());
				redirect = (CheckoutRedirect)CheckoutCartBuilder.getInstance().parseToJAXB(source); 

				response.setStatus(302);
				response.sendRedirect(redirect.getRedirectUrl()); 

				return(true);
				}
			catch (Throwable t)
				{
				t.printStackTrace();
				NzLog.logException("Unable to redirect to google cart for account: " + accountId + ", to address: " + (redirect != null ? redirect.getRedirectUrl() : "null"), t);
				}
			}
		catch (Throwable t)
			{
			NzLog.logException("Unable to send request for google cart address message for account: " + accountId, t);
			}
		return(false);
		}

	/**
	 * Does this billing handler handle checkout synchronously, or must we wait for
	 * some kind of asynchronous message indicating the success of failure of the
	 & checkout proocess?
	 **/
	public		boolean		isSynchronous()
		{
		return(false);
		}

	/**
	 * There is a little example code for building carts, but for
	 * alternative 1, in the jsp files found  in the top
	 * diretory of the example War file for java 1.5 on
	 * google's site
	 **/
	private		String		buildEncodedCart(
						String accountId,
						String pendingOrderId,
						Strings orderItemIds,
						String cost,
						String taxAmount,
						String discount,
						String totalAmount,
						Strings itemizedCosts,
						Strings itemizedCostsDescriptions,
						Strings itemizedDiscountIds,
						Strings itemizedDiscounts,
						Strings itemizedDiscountsDescriptions,
						String customerReference) throws JAXBException, Exception
		{
		String mKey = getMerchantKey();
  		String mId = getMerchantID();

		CheckoutCartBuilder pBuilder = null;
		pBuilder = CheckoutCartBuilder.getInstance();

		List itemList = new ArrayList();
		for (int i = 0; i < itemizedCosts.size(); ++i)
			{
			Item item = pBuilder.createShoppingItem(itemizedCostsDescriptions.get(i), NzOrderItemOperations.getOrderItemDescription(orderItemIds.get(i)), 1, Utility.toFloat(itemizedCosts.get(i)), null, null, null);
			itemList.add(item);
			}
		for (int i = 0; i < itemizedDiscounts.size(); ++i)
			{
			Item item = pBuilder.createShoppingItem(itemizedDiscountIds.get(i), itemizedDiscountsDescriptions.get(i), 1, -Utility.toFloat(itemizedDiscounts.get(i)), null, null, null);
			itemList.add(item);
			}

		ShoppingCart cart = pBuilder.createShoppingCart(itemList, null, null);

		// Unfortunately there is no programmatic way to create an empty MerchantCheckoutFlowSupport
		// taxTable = null;
		USStateArea stateArea = pBuilder.createStateArea("CO");
		DefaultTaxRule taxRule = pBuilder.createDefaultTaxRule(stateArea, 0.0F, false);
		List ruleList = new ArrayList();
		ruleList.add(taxRule);
		DefaultTaxTable taxTable = pBuilder.createDefaultTaxTable(ruleList);

		MerchantCheckoutFlowSupport flowSupport = pBuilder.createMerchantSupport(null, taxTable, null, null, null, null);

		flowSupport.setContinueShoppingUrl("http://" + NzConfigurationResources.get(NziConstants.NZ_APPLICATION_DOMAIN_NAME) + "/nav?action=portfolio-statements");

		AnyTypeImpl pendingOrderIdHolder = new AnyTypeImpl();
		pendingOrderIdHolder.setAny(pendingOrderId);
		cart.setMerchantPrivateData(pendingOrderIdHolder);

		Document cartDom = pBuilder.createCheckoutCart(cart, flowSupport);
		String clearXml = pBuilder.unmarshal(cartDom);

		return(clearXml);
		}

	}

Anyone who uses it has run into the X.rpm has 226 dependencies, of which your system will have 10 unresolved, of various unknown degrees of criticality. Attempting to resolve those 10 involves serveral more rpm files, that have their own 826 dependcies, of which yet more are unresolved, of course.

Not to be pointing fingers, but if people were A. actually to want to get work done, or to B. have a life outside of masturbating their operating systems, then this situation would not have gone on like this for as long as it has. I am in the A category. Masturbating OSes is a whole lotta fun, but it interferes with A.

One solution, which seems simple and straight forward, something the *nix’s have usually been pretty good at, is to have several global repositories on the net. Actually they can be distributed anyway people see fit, the repositories just have to be registered and secure.

From these repositories, the RPM install process, say for App-X, has a list of App-X files, its dependent files, and access to their dependencies, recursively, and just downloads and installs all the software required to run the darn thing.

For example, an ‘install program’ would just be a list of pseudo URIs of the files and libs it needs, the URIs encoding the OS species, version number, and whatever else is needed to uniquely identify a file of some sort.

This could be expanded so that these ‘neo rpm’ scripts could download and run programs locally, being a kind of service that runs on your box, whether the component programs of the service is stored / cached locally or not - a kind of mirror image of SOA - but that is for another day.

Â

When people hype CSS over the html Table, I think they do not understand the functionality that the Table brings to the table. I think they do not understand the history of hard-coded coordinates versus automatic layouts. It is called ‘dynamic resizability’. You can set the minimum and maximum distance in a table and have the table resize based on the size of its container.

Not so CSS, which hearkens back to the bad old days under MSFT Windows.

So often, when the viewer of a page of CSS resizes their font, so that they can read the text, it overlaps itself and nearby text and images. How quaint.

2. CSS mixes layout and appearance, and soon in CSS 3, behavior.

Right now, common practice is to put everything into one CSS file, so if you want to add a new skin appearance, the new skin has to duplicate layout, and soon, behavior information along with colors and font sizes. Or what if some skins are behavior-specific, for example with and without javascript support.

You can see where this is leading… we will need an object-oriented CSS, that supports packages so that the CSS ‘programmer’ will be able to manage the complexities.

So what we will end up with is html elements that have several pointers (or ‘tags’ if you wish) that each refer to either their appearance, layout or behavior aspects. And to make it a little more sensical, the CSS behavior should just be a binding to javascript or PHP [update: or Ruby!] or something. And while we are at it, might as well add a tag for the content to permit dynamic content.

So what we will have at the end of the road, after we get through this adolescent infatuation with toys that mimic the good old days of Windows 95 et. al, is:

HTML Element

• Appearance id
• Layout id (we are talking springs, struts, tables, and dumb margins only if needed)
• Behavior binding id (i.e. onclick boundto store_data)
• Implementation id (the javascript file location with a store_data method)
• Content id
• Importance quotient id
• Semantic meaning id
• Help id

3. It is more difficult for search engines to determine what is being done to the content which they must know in order to see what is of importance on the page.

No, the emphasis tags really do not take the place of this analysis, because ‘really’ is really not what this post is all about.

4. CSS is overly powerful

For example: font-size is multiplicative (if another element and its child both have font size 8em, then the child will be 64em).

The law of against designing a language that has numerous unintended consequences has yet again been violated, very much in the spirit of C++. You cannot just look at a piece of code and know what it does without CLOSELY examining the N^N-1 possible consequences of all other assignments in this and any included files.

Similarly for the overly broad assignment such as:

.class a

which assigns ‘a’ some style which has every chance of having been assigned at least one other style somewhere else in the CSS hierarchy. Maybe. Which came first? in which file? And how did that precedence of CSS assignments go again?

So in conclusion,

CSS has the mishappen non-structure of assembly language [although I like the limited instruction set of asm languages, so this is an insult to them], the syntactically over-powering ‘why use a hammer when an atom bomb will do’ approach of C++, with the spaghetti-inducing compression of responsibilities and nostalgic lack of runtime layout tools of pre-Java MSFT Windows.

…aka CSS sucks.

[Oh, and it would be nice to see a syntax/completeness checker tool. But I bet that would just add another layer of incompatible implementation to deal with on top of all the others] [Update: FireBug does help some, tracing all the inheritance trees for you. Does no one else see how wacko this is? Yet another specification that tries to be too many things].

So is everyone writing their own DIY javascript debuggers? And, with DOM/HTML, absolute positioning layout engines? And widget toolkits. And Flash-like animation tools? And syntax checkers? And println and logging tools?

Sometimes I think our industry is making leaps and bounds every month - new things better things all the time.

And then there’s now.

Is it just that everyone is on the server bandwagon hopping from J2EE to Struts, to Spring to Ruby on Rails to….and this is keeping them all busy?

Arguably it should be the browser manufacturers that write the javascript debuggers for their browser - seems like attracting developers is a good thing if one wants to dominate such a market…

Anyone research MSFT’s JavaScript debugger lately?

BWTFDIK.

More on the unpleasant state of some of these haphazard technologies later (I am refering[sic] to Javascript and CSS) - but as I write the code I came face to face a number of times with the option to either download and use somebody else’s code or write my own.

 Given that Not Invented Here (NIH) is a perjorative it is obviously unpopular to advocate writing ones own routines when reusing someone elses will ‘work’.

 But there are good reasons to write ones own:

1. When it is faster to write the code that it is to understand how to use the often overly generalized and overly documented alternative (why does a logger, or a dispatch routine, take a whole book to document?).

2. When there is anticipation that the functionality that you require does not quite fit into the set of featrures offered by the exisintg alternatives. A collary to #1, really. It is that the time spent trying to learn someone elses code well-enough to A. use it and B. tweak it often is much greater than the time it takes to write it themselves, which comes with a deep understanding that allows one to customize the solution in the future.

3. The alternatives are so general that they hog way more resources than what is desired, or necessary

This is all extemporaneously written and it is very late at night - and there are more reasons than listed above - but the whole thing should be able to be expressed by an equation:

S - set of features required
TS - time to implement those features
SP - giant set of features offered by the ‘popular’ and more general solutions
TPÂ - The time it will take to understand and customize the features to solve the problem we are trying to solve

I am saying that TS is often less, way less, than TP because S is way less, and somewhat different, than SP - and that over time the indepth understanding of the code that is hand-rolled allows one to customize their solution over time to gain market advantage over the competition.

I am not talking about writing one’s own web browser here (wish I was) or database, typically, but about things like log4j, Junit, Struts, etc.

It is my suspicion that the popularity of this ‘rather download it than write it’ attitiude is because

1. The current industry hype says we should

2. Many programmers do not know how to write code - but stitching together someone else’s code is manageable and delays are more justifyable to management if they can point their finger at a tool insetad of their own code.

3. Many programmers who choose what tool to use do not care if they understand the tool or not - they will be on to something else soon enough.

4. Management wants interchangeable coder-bots and everything that will make coder-bots skill-sets more indentical, like understanding the toolkits that their programmers are downloading- makes them that more interchangeable (i.e. easier to hire and fire).

5. Hand rolled code does not get a cool name that can be put on a resume.

So, here’s an idea, let’s start naming our custom software. Let’s see, I just wrote Dispatchertron 1.0., LoggerSharp and TestBot3000 [this works great - it is able to make a browser navigate the site at random - filling in forms as it encounters them with randomly valid data - can’t wait to see if it can be made to handle stuff like uploads…].

Don’t ya think they’ll look great on a resume? :-)

Â

The advantages of DIY are numerous:

1. Ability to fix bugs yourselves

2. Abiltiy to control the release schedule

3. Ability to control the feature set

4. Abiltiy to control the dependencies

5. Competitive advantage

 Using someone elses code does not let a corp focus on core competancies if it takes them more staff hours to understand and use the externally determined feature set and find and fix their bugs than it does to write a little bit of code that does what you need now - written in such a fashion that it is expandable (Agile is good to a point - but until computers program computers - it is often quicker in the long run to think ahead a little) in the direction the corp wants to go.

Â

What Obsidian is, and what I think the GUI should evolve to be, is…a meta GUI.

Meta-GUI: Where the user sits down and can choose some data and choose operations to perform on that data, AND choose how they want to see and work with the set of available data and see and work with that particular data of interest and see and work with the set of operations and see and work with the operation itself in action and see and work with the results.

All this so easy that a CEO can do it. Actually, Obsidian is more targeted towards ordinary people - but deep down, way deep, CEOs - who typically are targetted because of their software-purchasing budget powers - are ordinary people too [OK, sorry for the post market bubble bursting CEO humor].

Anyway, as you can see, this meta GUI is a very general flexible description of how humans interact with computers. It is just that, currently, most of these things in most applications are FROZEN by the programmer - so that the user has NO flexibility - they are in a multi-dimensional straight-jacket (and don’t talk to me about ’skins’ - The ability to change the application’s colors…? whoo hoo!]

This degree of flexibility takes the GUI beyond the physical metaphors we have been tied to since Xerox PARC - or rather builds upon them to make the user some kind of super-being in the virtual reality of the computer.

The challenges the Obsidian Framework has are - well there is really only one:

How to make using the GUI with so much flexibility as easy to use as, say, using a TV? or driving a car?

Well, there I go asking a question and answering it in the same sentence… :-)

The solution Obsidan itself takes, and it is the easy-way-out so to speak, but if you think about it there is no other answer for a generic framework supporting this kind of GUI, is

To Punt.

To make the Meta-GUI itself a plug in.

The key here is to realize that the Meta-GUI is somewhat recursive. No, that’s not right. It is like those Russian dolls where inside one doll is another, and inside that is another, etc. Except that any of the dolls can contain any of the other dolls - and/or itself. [and, unfortunatately, this is not the typical ‘container isa part’ relationship, though visually that is often what it looks like].

I.E. a Meta GUI defines interactions between other plug-in GUIs, that may and often do define iteractions with (for example a list, or a search field) other GUIs and on and on. And of course there is a GUI to displays the choices of possibleMeta GUIs, and a GUI to choose the GUI that lists Meta GUIs. All plugins of course.

It is the flexibility of this ‘Universe of Choices’, where the atoms are more or less well-defined but what you can build with them is not - and how do you ‘boot’ such a universe? - that makes writing Obsidian somewhat of a challange.

Oh, yeah, and there is how to make all these plugins - functional plugins, GUI plugins, and data source plugins, plugin-customizer plugins, plugin-network-builder plugins all work together.

The last post talked about how it is these types of frameworks, no matter how crippled thye have been in the past - that have spawned large numbers of very specialized, one-of-a-kind ’software screw’ factories’ (ex: Photoshop). The point being that the specification of how to make a plug-in just has to be understandable and to actually work - it does not have to be created by some consortium populated by big companies with their fiduciary desire and need to over complexify everything.

So that is one key to how Obsidian is being designed… Keep it small, simple and stupid. Otherwise my poor brain is just too lazy these days to Grok it. There is enough inherent challenges for the brain with respect to Meta GUIs - no reason to add more.

But sometimes small, simple and stupid creates its own complexitites - especially with regards to debugging.

For example, there is only one kind of Data in the whole framework - in order that every plugin, and every type of plugin, knows what to expect - and it can be interesting to debug a piece of data as it winds itself through the system.

[Which creates a need for a god-like set of choosable nested GUIs that looks at the Meta GUI from the programmers perspective…]

Next… more on the architectural choices taken to make this all work and make it implementable in finite time… oh, and maintainable by someone with not a lot of free time.