What was I thinking...

Someone else but mee...

2006-05-19T01:28:00.000-07:00

that have get used to the fact that Firefox crashes frequently?

2006-05-18T06:22:00.000-07:00

"Blåser av lite ånga" för att tala svengelska, "som du gör".

Adobe är ett företag som är som en nagel i ögat,
man blir alltid besviken på dom.
Inte nog med att dom har svindyra priser på sina produkter
dom har mutat in en alldeles förstor del av marknaden med
sitt PDF format (visst PDF är en öppen specifikation, eller
till och med en öppen standard, vad vet jag. Och sure bellman
det funkar säkert skitbra inom trycke industrin med väl
inkörda rutiner kring det formatet)

Men har du prövat att läsa en PDF på en PalmPilot någon gång?

Inte nog med att man måste konvertera skiten innan man dunkar upp
den (vilket tar otroligt lång tid att göra om PDF-filen är något
längre). När man väl laddat upp skiten tar det 200 år (ingen överdrift
jag har mätt) att öppna varje sida. 200 år!!!
Mao skiten är oanvändbar.

Just läsa dokument på en Palm är imo en av dom stora fördelarna.
Du kan ha med dig ett helt (mindre) biblotek (om det är pdf blir det
ännu mindre) på ett SD-kort, dvs läsning för hela semestern, i en
liten hand-moj. Du kan till och med ta med dig ett par långfilmer.

Men om du tänker ta med dig PDF får du ladda upp ditt tåla mod.
Och när du ändå håller på ladda upp lite för mig med, jag
tänker inte göra det!!

"Now where did I put that shotgun?"

/Yours 'psychotic bastard' truly

Base Ad:
http://basecamphq.com/?referrer=colliberty
If your not already using it, start us it NOW.
(and remember to say colliberty when you join up :-)

Thing I really hate (today)

2006-03-06T04:32:00.000-08:00

Java applets on websites!

Adobe software, and specially PDFs, but the rest of their shit such pretty much too.
(So why can't I find a replacement for Indesign or Photoshop for instance, haven't got a clue?)

Flash IDE environment, it's not programming, it's something else.

I think I hate Java Applets (pretty much all about Java I hate) and Adobe more than I dislike Microsoft. Microsoft maybe striving for monopoly but hey if they are successful it's only because the other guys wasn't good enough. Microsoft product have had a not always bad reputation, some of the stuff they do is accually quite good in comparison.

Things I'm considering switching to Apple and MacOSX though. I'm willing to try it anyway.
Linux on the desktop, haven't been convinced so far.

Oh yeah, I almost forgot.
Using webbapplications instead of REAL applications, SUCKS!
The reason is that webbrowsers do not deliver the stability that you expect from a modern OS.
E.g. your browser may crash, because your doing several thing at the same time (as you DO) and one of the things you do is loading PDF file, which crashes the whole fucking thing.
Ok, you could run two different instances of the webbrowser (at least with IE) and if one crashes it only crashes that instance, but when you dont have tab-browsing and if your supposted to keep all things seperat you would consume allot of resources of each instance (because you DO have allot of browser windows going).
And also, the point oyu remember to create the browser in seperate instance is always right after it crashes.

No, ajax webapps are the same thing throwing yourself back in to Windows 95 or MacOS 9, is that really what you want! I suggest you thing about that for a while before going the Ajax route for your next application.

This said it doesn't mean that Ajax is bad for webapps (they already have this problems anyway), just dont try to replace REAL applications with webapps just because Ajax make it look and feel like one.

Johari Me

2006-02-17T00:48:00.000-08:00

http://kevan.org/johari?name=JohanC

Something I tried too avoid...

2006-02-16T03:14:00.000-08:00

I always been a strong Zope advocate, but I find myself willing to step of the band-wagon because Zope isn't developing in the direction that I like. It's starting to become something that I was trying to avoid when I "joined up" (that would be J2EE like mastodont frameworks).

As you might have notice I'm not a big fan of Zope 3, and I see Zope 3 (and CMF) as technologies that are blocking Zope from evolving into that I would like to have.
Also the key feature of Zope, the Object Database (ZODB) is starting to get in the way, it just hasn't evolved enough to battle the competition from the rising of the ORMs.

The main benefit of having an transparent object database in the bottom is that persistent isn't an issue, it's handled automatically. Well you get that with an ORM too, and you don't have to rely on the database to handle version, your don't get a rigid object hierarchy (in fact you can have high dimensional object hierarchies if you'd like), you have index and fast query facilities from scratch without having to define your model twice (once for the objects and once for the ZCatalog).

Conclusion, Zope was great when it came, it was new it was object-originated, it was dynamic typing and dynamic data models, it was fresh.

Now it grown out of proportion and does seem to keep up, it's heavy, it's a dinosaur.

Flexibility vs. Productivity

2006-02-16T02:43:00.000-08:00

I've always been a fan of flexibility in the framework, it's something that attracted me with the Zope framework from the beginning (you could add a property to any object at any time without having to change your application model, the AM was in a sense real-time changeable.

Again quoting David Heinemeier Hansson:

"I often find I want to trade flexibility for productivity. i am fine with saying, I could just do it this way, or I could do it 10 times faster."

Now, David isn't just good looking and smart, he's "hyper cool".

I find that I now days also want to trade flexibility for productivity. I don't have the time configuring Zope 3 apps, I just want the damn thing on the net with a minimums of effort.

Ok, so I'm starting to compare Zope 3 and Rails. Not have had a particularly close look at Rails (yet) I'm starting to get the feeling that both Zope 3 and Rails try to do aspect-originated stuff.
The main difference is that Rails stay true to the philosophy of the language (Ruby) where Zope 3 stray of into different non Pythonic creations, adding the flexibility but with the cost of bad usablility. Rails stray for beauty in code, and I believe code is the best way to make programs, not configurations (which Zope 3 relies on heavily).

For where I am now Rails seems to lack the co-location problems (which IMO is one of the largest problems with Zope 3). Rails also seems more true to the MCV pattern, even though Zope 3 has that pattern, it's not very well constituted to the user (calling controllers view classes for instance, it's just confusing).

Ruby on rails Partials!!!

2006-02-16T00:18:00.000-08:00

We do it right (when Zope doesn't).
Ruby on rrails have partial which are sub-template that ar like includes but like subrutins at the sametime, os you can pass arguments.

Well, that just kicks TAL macros in the ...

I rebember how surpriced I was when I realized that METALs didn't compile to "module like" objects ith sub-routines. Haven't use TAL since then (the system I made was just over complicated and ugle, and no I didn't put business logic in the templates).

2006-02-16T00:14:00.000-08:00

More excellent quote from the creator of Ruby on Rails framework David Heinemeier Hansson:

"... because javascript is, what's the word, Horrible!"

Finally someone that can "think"!!!

2006-02-15T23:51:00.000-08:00

"I like Ruby so much I want to use Ruby everywhere (in Ruby-on-rails), in the model, in the controllers, in the confituation, and in the VIEWS.
And now some of you who has been burned badly before by using a real programing language in the templates are screeming "NOOOO, you can not do this. If you do that the end of the world is coming, people will flood their views with logic and conditions, and it will be a mess and you never recover."
Ah, No! Because there is no such thing as taking the logic out of the view. The view will always have logic, it will always have loops it will always have conditions. You just call them something else if that make you feel good. your still putting logic in the view, and the key realization is that that's not a bad thing. Logic belong in view because we are making dynamic web applications not just this static things. So logic in views good!" -- David Heinemeier Hansson, creator of Ruby on Rails framework (freely quoted by me :-)
Told ya!

All Go for Django...

2006-01-22T06:47:00.000-08:00

I'm most probably gonne use Django for my little project.
I need a framework that I don't have to fight but still provides me with an efficient tool to make things fast.

My initial assuption that Django would get in my way have been shattered enough to make me put my hopes in Django. Another reason is that I don't have time or want to search any more, I want to start prototyping.

I think an apology might be in place

2006-01-22T02:26:00.000-08:00

I must admit I didn't give Django a fair examination, now that I have visited it I am much more happy about it. As I mention before it does what I want but not in a fasion I like.

Well, the easy of making applikations with Django have convinced me that running
setup commands to get started isn't that bad after all.

I'm suspecting I will run into limitations of Django but reading the tutorial was really fun.
Allot of stuff is made for you automatically.

I think I'll keep reviewing this for a while.

"Google"

2006-01-19T01:32:00.000-08:00

The number one top ten of stupid answer a person could give another person asking a question on a online-forum or mailing-list is "Google", even so the answer is give more often when answers that actually help people.

The main reason for people not realizing how stupid they behave is they fail to recognize that people are different and that a large amount of people isn't like them.
Correction, they know that people are different and that people are not like them, but instead of trying to understand how they work and accept them as they are they incorrectly judge these people as being stupid.

"Repeat after me three times: Being different or thinking different isn't the same as being stupid."

Many people that ask questions on online-forum prefer to use relational methods for gathering information and are rather taught fact by someone in person than seeking it in solitude.
You could say that their information function is relation based or extrovert, compared to "the rational person" who's function is introvert and maybe more goal oriented (short term closure).

A false sense of all mighty knowledge
For "the rational person" the difference in knowing fact and knowing how to get facts are now days getting kind of blurred, and (of course) I blame the Internet and in particular Google ;-)
This is a contributing factor in the "Google" answer on online questions because the "know-it-all" person knows he could use Google to find the answer, hence he has a feeling of knowing the answer and then feels entitled to actually answer it (with "Google"). When in fact he didn't have the answer or worse he did but didn't put an afford in formulating an answer him self (because it's easier and "everybody should be tough to do thing my way").

This will not end, but as with the Swedish language protectionists at "skrivihop.nu", "rational people" can learn new behaviour, the problem is no one have told them, until now.
Well some rational people doesn't want to change there behaviour, but the rest of us have already learned to ignore them :-)

Cocktail party problem

2006-01-18T06:59:00.000-08:00

Cocktail party problem or as I used to call it when I when to the university, the cocktail problem. It turned out to be a completely different problem though.

Anyway this is a really cool example on how to use the SOM-neural network to separate two sound sources. Accually the example works so well I'm starting to think they are faking it.
I might also have missed something very important, being a 1200CC chaos machine and all.

There is just too much stuff out there

2006-01-17T02:11:00.000-08:00

After spending some time researching different web app. solutions in Python (while trying to avoid treason by looking at Rails directly ;-) I'm over whelmed. There is just too much project going on.
I guess doing rdb based web apps in python is in fashion *lol*

TurboGear: Same same different different

2006-01-17T01:51:00.000-08:00

TurboGear is really just some other stuff pack together to a package, it might accually be pretty brilliant.

TurboGear combineds MochiKit (Javascript libarary), Kid (TAL and XSLT inspired XML template language), CherryPy (web app. framework) and SQLObject (ORM). It also uses ElementTree (Fredrik Lunds XML library), FormEncode (form validation framework), TestGears (unit-test) , and json-py (json-python bridge).

Accually this are all software that sound amazingly interesting and those I haven't check out (and approved like SQLObject, which imo is the best Python ORM out there, and CherryPy, which imo is the best simple web app. framework out there even though I'm still looking.

Kit is a possiblity, I will either choose Kit or TAL I guess, it all depends if Kit does what TAL doesn't do for me, e.g. let me define a component library of visual components (not macros).

No go for Django

2006-01-17T01:47:00.000-08:00

I'm pretty sure Django is what I want, or should I say Django does what I want to do, but I'm pretty sure I don't want Django to "tell" me how to do it.

Cheetah Template

2006-01-16T09:04:00.000-08:00

CherryPy got an bonus tutorial but it required Cheetah Template too run so I had to get that and check it out.

Well they are claming to "encourages clean separation of content, graphic design, and program code", but I can't for the world see how. It's basically Python Classes written in HTML.

One thing that made me interested was the fact that you could inherite a template from a sub-template. But after a time of thinking I recall why this is a bad idea. The one thing I hat the most in TAL is METAL, the macro language in TAL. METAL lets you reuse snippets defined in other template (METAL templates).

Well the bad thing about this is (part from the METAL implementation being unintuitive to a Python programmer because snippets are included not callable which would have made it possible to give arguments to a snippet).
Ok the bad thing (again) is co-location and co-location leads to unmanagable code, if you don't believe me check out Plone and try to change the site design.

I want to have a template language that uses layers instead of inheritance, that's how I work now days. E.g. I create a top layer template, it calls a set of renderNextLayer methods (usually just on called renderContent, more complex designs then that is accutally very rare).
When I call the top layer template I give it the renderContent callable as an argument.
Off couse this method works in all template languages that allow you to supply variable names including Cheetah.

Simple but slow cherry

2006-01-16T09:00:00.000-08:00

One of the things that stand-out when acctually running CherryPy is that it's remarkably slow. For a single use with the most simples Hello World it take almost secs to return a page, I would have expected a simple web app. framework to be faster, even the monolit Zope is much faster (not starting up though but with few Products installed that ain't that slow either).

Webware

2006-01-16T08:59:00.000-08:00

Well I checked out Webware for 5 minutes, and I can only say that I don't have reason for evaluating futher. If I should use a complex framework I would use Zope 3.

Yield your self

2006-01-16T07:31:00.001-08:00

Fantastic!

I just tried the tutorial example #09 in the CherryPy distribution and that's all about generators. Namely you can public a generator factory, using yield to return bits and pieces of the page with out bothering to append the data in a temp variable.

How cool is that (well a little bit, a tiny-iny bit, oh sod of).

Here's the example:

"""
Bonus Tutorial: Using generators to return result bodies

Instead of returning a complete result string, you 
can use the yield statement to return one result part 
after another. This may be convenient in situations 
where using a template package like CherryPy or Cheetah
would be overkill, and messy string concatenation too 
uncool. ;-)
"""

import cherrypy


class GeneratorDemo:
 
   def header(self):
       return "<html><body><h2>Generators rule!</h2>"
 
   def footer(self):
       return "</body></html>"
 
   def index(self):
       # Let's make up a list of users for presentation purposes
       users = ['Remi', 'Carlos', 'Hendrik', 'Lorenzo Lamas']
     
       # Every yield line adds one part to the total result body.
       yield self.header()
       yield "<h3>List of users:</h3>"
     
       for user in users:
           yield "%s
" % user
         
       yield self.footer()
   index.exposed = True

cherrypy.root = GeneratorDemo()


if __name__ == '__main__':
   cherrypy.config.update(file = 'tutorial.conf')
   cherrypy.server.start()

Jag har varit otrogen...

2006-01-16T00:41:00.000-08:00

Jag har dom senaste 5 åren jobbat med ett ramverk för webbapplikationer om heter Zope, det är ett komplext och kompetent system med många fiffiga finesser och allt man behöver är inkluderat (webbserver, scriptspråk, transkationsserver, databas, säkerhet med mera).

På senare tid har en ny generation (den tredje generationen) Zope 3 av Zope växt fram och efter att ha bråkat med Zope 3 större del av hösten kan jag nu lägga den på hylla (eftersom uppdraget är där Zope 3 användes är slut).

Men det goda i det hela är att jag börjat omvärdera hur lämpligt Zope är för att lösa alla tänkbara problem. Även om jag fortfarande anser att Zope är extremt lämpligt för webbpubliceringsapplikationer som CMS, e-handel, Intranet och portaler är det inte alltid det bästa verktyget för jobbet. Faktum är att jag många gånger misslyckats med Zope, egentligen lika många gånger som jag lyckats.

Zope 3 är visserligen mycket renare än in föregångare (Zope 2) och det innebär att det både
är enklare att lyfta in externa lösningar in i Zope 3 och att Zope 3's komponenter enklare
kan återanvändas utanför Zope 3. Men Zope 3 dikterar fortfarande, och kanske till och med
i större utsträckning än Zope 2, hur man skall designa sin webbapplikationer.

Enter CherryPy (vilket är den första i en trolig rad av Python baserade webbapplikationer ramverk som jag nu kommer att titta på för ett framtida spel projekt).

CherryPy har inte hälften av alla bells&whistles som Zope plattformen erbjuder, det mest
signifikanta är troligen avsaknaden av säkerhetssystem men det är en enkelt och strait forvard sätta att bygga webbapplikationer.

Enkelt beskriver kan man säga att man skapar klasser som man sedan instantierar och till delar
till en objekthierarki med start i cherrypy.root. Objekten metoder kan publicerar till webben genom antingen en dekorator eller att man tilldelar variabeln published=True på "metoden" (man kan göra sånt i Python eftersom funktioner och metoder är objekt).

Tre metoder kan användas som "default" metod, index(*arg, **kw), default(*arg, *kw), och __call__.
Det normala är att använda index eller default där index har företräde framför default.
Skillnaden mellan dom båda är att argumenten för index fås från webb requesten, medan argumenten för default är en kombination av webb request variabler och ej matchade URL element.

Exempel:

URL Anrop
/ root.index()
/?hello=world root.index(**kw={'hello':'world'})
/hello/kitten root.default(*arg=('hello', kitten')
/hello/kitten?hello=world root.default(*arg=('hello', kitten', **kw={'hello':'world'})

Hänger du med, läs CherryPys tutorial, dom förklarar det bättre.

CherryPy saknar skriptspråk eller snarare är skriptspråk agnostisk, vilket passar mig fin fint eftersom jag troligen vill skapa mitt eget skriptspråk (en variant av Zopes TAL språk).

CherryPy erbjuder inte så mycket mer, en inbyggd webserver som inte verkar speciellt imponerande, en filter funktion för att patcha in låg nivå hantering av request och response, en väldigt medioker konfigurerings funktion baserat på Pythons inbyggda .ini parser (men den räcker till väldigt bra för mina mål, man kan jämföra den med Zope3s mastodont konfigureringsspråk).

En sak jag är glad att CherryPy har out-of-the-box är sessions hantering, den är naturligtvis inte lika komplicerad som Zopes (duh!) men räcker troligen till för att hålla en cache av session
data för en användare.

Som jag nämde ovan saknar CherryPy ett system för säkerhet, visserligen har dom ett system för att publicera objekt och metoder (default är att metoder inte är accessbara från webben) men det finns inget system att hantera användare/grupper och inget system för rättigheter/roller.

Om jag väljer att gå vidare med CherryPy är det första jag kommer försöka göra att integrera
Zope 3's zope.security med CherryPy så jag kan definera åtkomsträttigheter.

Nästa ramverk för granskning blir django...
Vi hörs!

SQLObject och Zope3 security

2006-01-12T13:12:00.000-08:00

(Jag kanske borde ha en teknik blogg istället för att maila er stupikvarten!)

Så jag skrev det på i min blogg istället.

I alla fall, mitt äventyr med SQLObject går vidare. Nästa steg i problematiken är att förse dom stackars objekten med en vettig säkerhets modell.

Enter Zope3. Detta är redan gjorts SQLOS projektet, men eftersom jag inte vill använda Zope3 som det är och absolute inte vill använda mig av "Containers" i ZODB
för att husera object (jag vill att dom skall få sväva fritt i sitt Python universum, eller något "slightly" mindre poetiskt). Så...

Så använder jag bara Zope3s zope.security, vilket pga av att zope3 är väldigt modulärat uppbyggt och har få dumheter (a la Acquisition
eller ExtensionClasses), är det super enkelt att återanvända
(eller, det är Zope3 så det är inte enkel men det är super gör-bart och efter att man skruvat fast huvudet igen, vilket har en tendens att lossna efter att man läst Zope3s dokumentation över hur saker funkar internt).

En annan liten down side med zope.security är att man faktiskt måste implementera "allting", men byggstenarna och de inre mekanismerna finns där och det är inte speciellt mycket som är allting när allt kommer omkring.

Ett annan litet problem är att zope.security implementerar isinstance eftersom isinstance i __builtins__ inte kan hantera objekt wrappade i en Proxy (naturligtvis). SQLObject verkar enligt utsago från skaparen av SQLOS alt SQLObject använda isinstance på flertal ställen vilket
innebär att jag måste antingen byta ut den i __builtins__ (aj), monkey patch in den i SQLObject eller helt enkelt patcha SQLObject (SQLOS monkey patchar tror jag, det kommer jag nog också göra).

Ett annat plus med zope.security är att dom definerar om restricted python från zope 2 på ett återanvändbart sätt. Det man kan skapa med det är 1. säkra användar programmerbara objekt (till en moo), 2. en säker intrepetator (till samma moo).

Alltså man kan göra en säker pythonbaserad moo, all data kan hållas i en SQL server av ditt val (eller mitt, vilket troligen blir postgres kanske mysql) inklusive python kod objekt eftersom SQLObject har en pickle data type (dvs för dom databas back-ends som kan hantera blobar förstås).

Nu skall jag testa att använda eventnet för att skapa en enkel multi-user mud. Eventnet är en modul för en nätverksbaserad eventloop för spel som verkar lovande.