The core OS has been restructured to allow it to take advantage of all those cores in newer computers. So while we have the same body, it is all new under the hood.

The truth is that 3GHz is about the theoretical limit for clock speeds for the Intel x86 family. They’re not going to get faster. They are getting cheaper though. So now, instead of getting a processor that’s twice as fast every cycle, you get twice as many 3GHz processors. That’s all well and good, but much of the core OS has been built assuming one processor. So even though I’ve got a dual quad with 8 processors in the box, most of them are idle most of the time. That power is wasted.

Enter Snow Leopard. It restructures the way the OS divides and schedules tasks and supplies new apis for applications to parallelize logic to much improve processing throughput. Besides letting programmers take advantage of all of the Intel cores – OpenCL makes it easier to offload vector processing to the graphics processor – a largely underutilized resource most of the time.

The average non-technical user won’t see much change and that’s no surprise – but if this were “just a service pack” there wouldn’t be so many broken programs that need updating. The change is substantial and at this point, most application updates going forward are going to require Snow Leopard. Its not practical to build apps that take advantage of Snow Leopard and still work on older releases so this is the line in the sand.

Fortunately, Apple realized this and Snow Leopard is priced “almost free”. I’m not one to push people to upgrade working systems without a compelling reason.

However, eventually an update or a new application will come out that you’ll want and it will require Snow Leopard and this is why it is good that Apple made the barrier to updating very low. Certainly a forthcoming update to Jambalaya is going to be Snow Leopard only.

But now my availability is ramping up.

My San Diego contract is wrapping up early – at the end of January. I’ve been fully booked for so long that I haven’t got any leads and, really, I’m just looking for stuff I can do remotely. I like San Diego and I’d like to stay there so I guess I’d better get off my tail and start networking there.

If you’ve got any leads on software projects, send them along. My preference is Cocoa/iPhone, but web work is always good. I guess this is the time to really start marketing Jambalaya too.

BaseTen builds queries out of NSPredicates and NSPredicate supports an operator ‘like[cd]‘ where the c option is to ignore case and the d option is to ignore diacriticals (accents and other funny squiggles found in non-english text). Postgres does not offer an option to ignore diacriticals in search. So how to support this?

The good news is that the unicode characters are laid out such that taking the numeric value and taking the modulo of 128 (the size of the ascii table) results in the stripped version.

I wrote a PgPL/SQL function that converts every character in a string to its ascii equivalent, then compare those.

CREATE OR REPLACE FUNCTION asciify(unicode text) RETURNS text AS $$
DECLARE
    translated text;
BEGIN
    translated := '';
    FOR i in 1..(char_length(unicode)) LOOP
        translated := translated || chr(ascii(substring(unicode,i,1))%128);
    END LOOP;
    RETURN translated;
END;
$$ LANGUAGE plpgsql;

The asciify’d versions of Panama and Panamá will end up being Panama and I can do searches like

SELECT name from countries where asciify(name) ~* asciify(?);

and get the equivalent of a case insensitive and diacritical insensitive ‘like’.

Quite a change from the beginning of the year when my one client scaled back his work drastically. Too much work is a good problem to have in a busted economy. If this continues, I may have to farm some work out.

Unfortunately, part of the system required a servlet to handle http requests (using http as an RPC mechanism). I’ve used Jetty in the past with good results so I downloaded it. Despite the existence of a “plugin” for IDEA to work with it, the debugger never worked.

So I moved on to Tomcat. I finally got IDEA configured to use Tomcat, the debugger worked, but the servlet was ignored every time without any kind of error message being logged. Did it fail to link or something (it used a lot of external libs I had to bring in). No clue. I simplified the servlet to just printing “Hi there” and still it refused to load.

This resulted in a refamiliarization with web.xml files and all the rest of it. In disgust I switched back to Jetty. Jetty at least logged the errors to the console and I fixed all the link issues, but still no debug. Back to Tomcat but it still wouldn’t load my servlet at the url I wanted. Eventually, I found the invoker servlet settings, turned that on, and the servlet began to work.

The bottom line is that the entire J2EE architecture, the servlet containers, the zillion xml files specifying garbage I never want to change anyhow, all of it is MUCH TOO FRIGGIN COMPLICATED FOR WHAT IT DOES. Too many descriptors. Too much config. Too much cargo cult xml.

Compare to PHP where I just drop a file in a folder under document root and I’m good to go. Or rails, which is pretty much the same deal – just putting the file in the folder ought to be all that’s required to make the thing work.

I think this will be my last foray into Java hell. At least for a few years until I forget how stupid it all is again.

OTOH, EOF wasn’t perfect either. Having been doing Rails, I find I really like ActiveRecord. It strikes just the right balance between SQL and objects and I like its use of the database schema as the primary meta model.

So I was excited to learn about BaseTen. Right now it is PostgreSQL only, but that’s fine – I like PG. It allows for use of controllers and bindings like CoreData, but it is designed for multi-user use and it doesn’t have a separate model file – you just design the schema along with foreign key constraints and start using it. It really is kind of the best of all worlds. Bonus is it wires the database for notifications so applications stay in sync. In autocommit mode – all objects are hot sync’d. Usually this is exactly what you want for small business apps (think less than a dozen simultaneous users).

Definitely makes development of small business database backed apps easy.

I have a project coming up that would probably be a great Seaside candidate. The database has to be postgresql (according to the client). There is a native cocoa component – I’ll probably give BaseTen a try. For the web component, the obvious candidates are Rails (although I don’t know the state of Rails with PG – only mysql), and Seaside/Glorp – but I need to use Glorp to work like Active Record since the DB will be the master source of record for the schema.

Sadly, it doesn’t look like Glorp’s ActiveRecord on Squeak is ready for prime time, I might have to kind of finish that implementation.

I’ve just deployed my first soup to nuts rails application. Well, nearly. It certainly starts fast. Generate ActiveRecord classes for your tables using scripts and you’re off and doing basic CRUD.

However, its the little things that made the experience less than satisfactory. First – the changes in behavior moving from development to deployment were nerve wracking. I have rails running under apache on my laptop, no problem. On my production server, I cannot get byte one to come out of rails. Webrick works fine. Mongrel works. Rails cgi produces no errors, and no output. Even apache logs are totally silent. I don’t get it. For now it is running under mongrel – but I’ll have to put that behind apache and front it using modproxy. Irritating as hell.

Second, I set up memcachedкомпютри втора употреба on the advice of friends and was going to use it for my session cache. But it turns out that objects don’t get saved in the memcached – apparently you can only store plist kinds of structures. Objects get dropped. I spent several hours beating my head against this using the usual hammer for this nail – require_dependency. However, after listing every blessed model class as a dependency, it was still dropping a collection of objects. Back to the file based session cache.

Another thing that drove me nuts is all the magic values you can’t use for attribute names. I inherited this database and admittedly a bunch of columns and tables are stupidly named – however I kept running into problems with collisions with ActiveRecord extensions.

Another thing – camel vs underbar lowercase. You generally specify relationships as lower case names, that ActiveRecord uses to infer a class name. For instance, you specify the relationship as purchase_order and it figures you have a class PurchaseOrder that keeps its data in a table called purchase_orders with a foreign key purchase_order_id. This can all be overridden, but understanding which form to use where got pretty trying.

Reciprocal relationships – at some level of circularity, ActiveRecord falls over with stack level too deep on save. It isn’t even a very complex graph that does it in. It became necessary to remove a bunch of back references to get a save to work properly.

Overall, I’d say towards the end I spent more time debugging magic gone awry than I did building application functionality. So I have to chalk it up as a real learning experience, but not one I’m looking to repeat anytime soon. The lack of decent debugging facilities was really crippling – especially coming from seaside. ActiveRecord is cool, but it isn’t trouble free. Doing basic inheritance was a huge exercise in wackiness I’m not eager to repeat. If I hadn’t had a big old mysql database to build on top of, I probably would have used seaside instead.

So enough slamming – its not all bad. One thing that helped a LOT was the discovery of ActiveScaffold AS is AMAZING! I was able to throw together a coherent admin interface with it very quickly – its customization options are very powerful, and in the end I think the back office app will be about 80% AS and 20% task oriented workflow. That’s brilliant. A data driven sensible ajax interface almost instantly. Very cool.

I may do more ruby apps, there are some seriously powerful go-fast kinds of technologies, but much of the time savings this go-round was lost to flukey behavior that changed from environment to environment, and really lame debugging tools.

Rails is definitely a very mixed bag.

I mean, I can only learn so many frameworks at once. So here we go – working through Agile Web Development with Ruby on Rails.

The application was said to be written in Java. I know Java – I don’t like it, but I know it. If its small, I could be persuaded to pick up the maintenance.

However, I got a source drop and I was totally appalled. First, it suffers from the usual Java framework-itus.

Its J2EE – so we got Jetty container. They used Hibernate – so we have generated Java code based on some XML schema files. There’s also a mysql database – which duplicates the information in the Hibernate XML schema files. It uses cocoon – cocoon make use of xml and xsl to define navigation and transformations. There is also reporting that uses xsl. Workflows use flow – more xml only they used the Javascript extension so the workflows are actually defined using server side javascript.

Got all that? We have Spring, Coccon, Flow for Javascript (flowscript), Hibernate, Jetty, Javascript, Html, CSS, SQL, XSL and god knows how many dozens of distinct flavors of XML. For a 25 page web app. Wait, did you notice I didn’t mention Java? There is Java – the Hibernate generated classes are used – but indirectly – they may as well not exist at all since all the application code is some fractured XML or Javascript fragment stashed who knows where.

It seems we’ve lost track of something here. “Locality of Reference” In general, all the stuff that deals with the product selection page ought to be visible by looking into the file representing that page, then maybe drilling into components. The problem here is that, everytime I have to drill down, I have to switch languages. And context switches are bad for programmer productivity – mKay?

I’ve turned down the job. I don’t have time to learn all that junk for this little app. The client needs a new installation – for 25 pages that do mostly CRUD to mysql. If I do it, I’m thinking plain old PHP with an ORM. If I can find an ORM for PHP.

So far I’ve looked at Doctrine (not yet ready for production but it looks cool), Propel – and some others. The really off-putting bit is their slavish insistence on creating the xml mapping file – just like Hibernate. Of course, I have an existing database. The XML file they want is in the db. It just isn’t XML. Still, all the information is available for query – so why are they bothering me with this junk? Read the damn schema and make me some classes. I’ll eliminate the many to many mappings by hand. Sheesh. No wonder there’s a software crisis.

Hey framework people, stop making me write monkey code – figure out how to eliminate extra work – not make it. One meta model is enough.