What can’t be copied

Reading Beyond Free by Kevin Kelly. I’m about to start up my software testing business, One Shore (though I’m not entirely happy with the name, perhaps the wrong connotation), and I’m looking to learn about starting a business, trying to find the right angle, the right plan, the right market.

I’m pretty sure a QA site is a good idea, but I’m not sure what people want. I know I’m not much of a salesperson, and dreading cold calling to try and find contacts. I’ve been practicing by posting comments on blogs and emailing people I find insightful with questions, particularly about starting a business or networking.

Networking, that’s a word I don’t like. I’ve always had trouble with routers and firewalls, and social things like that.

So I’m trying to learn the “soft” side of business, when in truth, it’s the social side of life that needs practicing, and I’m far from experienced at it. And then there’s the worry that even if I figure everything else out, I’ve still got to provide value (and then convince people that I can provide it.)

But anyway, I found that presentation and here’s a list of qualities that I brainstormed that can’t be copied. The original example is “trust”:

  • Trust
  • Love
  • Quality
  • Humor
  • Originality
  • Reliability
  • Beauty
  • Genuineness
  • Expertise
  • Strength
  • Creativity
  • Personalization

Quality is not what I provide, but what I help them provide.

Expertise can be learned. There’s no monopoly there.

Reliability is something I’ll have to build.

Personalization isn’t my specialty

I’m not going to win any beauty contests

My wife thinks I’m funny, but she doesn’t get my best jokes.

I’m selling standard best practices, scratch originality

I’m a phony, but I could make my website more geniune — get rid of “we”

Looks like I’ll have to use my puny muscles to intimidate clients into hiring me.

Silverstripe CMS – good at what it does

I tried out Silverstripe, a new CMS that is getting a lot of buzz, mostly because it was used by the 2008 Democrat Convention, definitely a high profile site.

While I’m impressed with it’s usabilily and polish, I don’t think I’ll be using it. It’s a good product for what it does, but I think “Content Mangement System” is a bit of a stretch. “Page Content Editor” is a better definition.  Even menus are do it yourself.

On the one hand, that’s nice. The philosophy of “get out the way and let the PHP and CSS coders do their thing ” is a good one, but it still forces you to work within the confines of the framework. Granted, it does a good job of making the framework simple and intuitive to use. It’s not a byzantine structure like Drupal or Joomla, by design, but both of the big league PHP CMSes have way more features.

I’d lean towards building a simple plugin and having my functionality outside the CMS entirely. WSGI middleware might be a good candidate for this. But not only do small services need to be lightweight, they need to be responsive, and probably cacheable, and integrate with the CMS authorization and access scheme. External dynamic content can’t block the completion of an HTTP response.

Silverstripe is designed to be easy to use for content editors. Unfortunately, this boils down to a tiny, solved problem that every other app in the world already has — TinyMCE, the rich text javascript HTML editor. Of course, the real solution is a HTML widget built in the browser, or editing outside the browser.

One nice feature of Silverstripe that isn’t fully developed is virtual URLs. Unfortunately, it doesn’t allow a hierarchy, so you can’t just create a logical grouping of URLS like:

/about
/about/partners
/about/investors

That would make it worthwhile.

Building a template, a style, and a layout are all left up to the developer. It doesn’t look like styles or layout can be dictated on a per-page level. Which is okay, even desirable for simple sites.

All in all, if you’re looking for a slick, reliable content editor for a basic custom site, hire a good designer, and install Silverstripe, it’s better than most at what it does.

Oh yeah– one small complaint. The Silverstripe forums are littered with unanswered questions. It could be a huge selling point, but if you’re a small firm with some fat clients already in the bag, you can’t be faulted for not spending all your time giving out free support to all the potential would be small fry. A possible solution would be to hire an intern (not a slave; a well-compensated, inexperienced developer) to answer replies to questions posted by people who click a button next to their question labeled something like “gimme tier 1 support” and a forward to a paypal account where they can pay $5 or something.

The many ways of OOP in perl

Recently I’ve been dazzled by the diversity of half-baked object systems available  (or required if you’re going to use much in CPAN or a framework) in Perl, from Moose to Mouse to Mousse (no wait, that’s not it)  to  Class::InsideOut — when really all I want is automatic accessors and constructor inheritance (okay, and maybe mixins).

Only I don’t want o mess with autoload.  I don’t want some fancy (and limiting) is_a/has_a/one_to_many_to_some meta language either.  And I could probably create it myself in a month or two (and nobody would use it).

architectural waffling as a way of avoiding getting things done

And classes are much easier in python than perl, if a bit less flexible. In this case “only one way” definitely beats “TMTOWTDI”.  Mixins and dynamic method loading (a la) Ruby would be nice too though…

While mod_perl is the reason to use perl, what is the reason to use mod_perl? Performance and flexibility.

But those aren’t really applicable in a prototype. While I know perl better than Python, it’s about ties with Ruby. And if SimpleXML does what I want, why not use PHP, since it’s probably the language I can develop quickest in, and the one (besides java) with the clearest development, testing, and deployment process to me.

python and XML

markup.py does approximately what XML::Generator does, but in an easier (simpler) way.

I still prefer SimpleXML or almost even Castor or XMLBeans.

Markup may not be good enough for building RESTful web services, but I’m toying with switching the prototype ShoppingList web service over to python –just for fun. Building (and iterating) through complex hierarchies in python *is* nice. Nicer even than perl.

Anyway:

import markup

items = ( "Cookies", "Milk", "Apples" )  

doc = markup.page("xml") 
doc.shoppinglist() 
doc.items() 
i = 0 
for item in items:
    i = i + 1
    doc.item(item, id_=i, qty_=1)
doc.items.close()
doc.shoppinglist.close()

print doc

yields:

<shoppinglist>
<items>
<item id="1" qty="1">Cookies</item>
<item id="2" qty="1">Milk</item>
<item id="3" qty="1">Apples</item>
</items>
</shoppinglist>

Trouchelle PPM repository

Here’s the correct URL for trouchelle PPM repository.

http://trouchelle.com/perl/ppmrepview.pl

Note, they don’t carry anything that theoryx5.uwinnipeg.ca/ppms does.

So add them both to your Activestate PPM repo list

ppm repo add http://trouchelle.com/perl/ppmrepview.pl
ppm repo add http://theoryx5.uwinnipeg.ca/ppms

Java doesn’t inherit accessors?

Call me an idiot, but what good is java inheritance if it can’t even inherit accessors. Does that mean that you can’t inherit any methods or properties?

Maybe I just don’t know how to do it, but I’m suspicious the answer will be somewhere between “you shouldn’t do that” and “why would you want to do that?” which translates directly into “I don’t know what you’re talking about.”

Given a class “Bar” that extends class “Foo” which implements interface “DeeDum”


public interface DeeDum {
public String getDee();
public String getDum();
}

public class Foo implements DeeDum {
public String dee = "D";
public String dum;

public String getDee() { return dee; }
public String getDum() { return dum; }
}

public class Bar extends Foo {
public String dee = "DEE";
public String dum = "DUM";
}

Why doesn’t this work?


public static Bar mybar = new Bar();
Assert.assertEquals("DEE", mybar.getDee());
Assert.assertEquals("DUM", mybar.getDum());

I get “D” and null instead. In other words, Bar doesn’t inherit accessors. Somehow calling mybar.getDum() calls a static instance of class Foo and returns the static properties from the parent class. Even if the properties are overridden in the child class!

I can’t wrap my head around it. It’s the craziest thing in the world, and only slightly more deterministic than returning a randomly populated array of octal integers. Whenever I see something like this I smell a bad, deliberate design based on an incorrect pedantic notion. Still, it’s funny hearing from a crazy blind man why the sky is red, so if this is really the case, why can’t Java inherit accessors (and why did they choose such an odd alternative?)

Or am I just doing something wrong?

Object Oriented Perl and OOP Frameworks

My first real understanding of Object Oriented Perl was reading “Perl Testing: A Developer’s Notebook” which shows some simple basics, but doesn’t really cover things that can get tricky like nested and multiple inheritance. Recently, I’ve been looking a little closer, rereading perlobj, perltoot,perltooc, perlboot, and Learning Perl (chapter 11.)

I’ve been looking at a way to build a good base class that handles instantiation and initialization (new), but haven’t found a good way to inherit new in a functional way. Standard practice seems to be to have a base sub new() call $self->init() and then have sub init() call $self->SUPER::init() on down the stack.

My concern then is worrying about what order things happen in the @ISA list. You have to be very careful, and when you inherit from other frameworks, you can’t be too sure of what happens until it does. I don’t have a good example, just a general feeling of unease.

But I’ve been looking on CPAN at several frameworks. What I’d like is a mixin style of inheritance so that I can have a domain object that, based on context can:

  1. define domain objects as a simple hash
  2. persist to a database
  3. handle REST requests and return XML/JSON/HTML based on “Accept” type
  4. Generate XML in a safe way
  5. restrict access and actions based on user permissions

So I want a class system that doesn’t try to hide stuff in a stash. I want to treat it as a hash when it is a hash. I want the hash to map directly to XML, and methods to operate on that hash. Request processing and access control can probably be externalized.

The two main parts, DB persistence, and XML generation I’d love to inherit from base classes, but it doesn’t look like there’s anything that does a decent job.

XML::Generator seems like the only level of abstraction between XML::Simple and XML::DOM. Simple only has XMLOut which is really just “print” and DOM is well, DOM. XML::Generator has a simple array mechanism that will probably be enough for what I need, but doesn’t feel that safe. I’m not sure if ordering of similar elements is guaranteed. There was one other similar package that didn’t seem to have even that, but I don’t remember what it was. I can’t believe there’s nothing like Java’s XMLBeans or PHP’s SimpleXML.

OO persistence is really scary. The top three contenders seem to be Class::DBI, DBIx::Class, and Rose::DB. It sounds like Rose::DB is the best performance wise (by a lot — though performance shouldn’t be an issue at all.) I hear a lot of people saying essentially CDBI is out-dated, but it has, in my opinion, a much better API than DBIC. Apparently there are gotchas with CDBI, but the always cited ability to do joins is not one of them. But I don’t want a package that defines it’s own query language. I want to map objects to the database, not create objects out of database tables. Objects contain data, they don’t describe it.

OO Frameworks are also a non-starter. Classes and Moose seem to be top preferences here, but I looked at Moose and it doesn’t make sense, and seems to be a huge waste of resources. I’m not sure what it buys me other than *yet another* “special” jargon. Classes pragma doesn’t seem to buy me anything, since it looks like I have to write the same boilerplate for contructors and accessors. The documentation seems to be saying I won’t have to write tests for my constructors and accessors, because I can trust they did a good job. But if I just come up with a base class and a simple convention, I only have to write those tests once, myself. While it is a sad truth that in dynamic languages (and perl is perhaps more dynamic than just about anything but lisp) type typos don’t get caught until runtime, it’s usually a pretty obvious failure. I don’t need to check my package name to figure out why my $foo can’t unstrap() it’s {bar}