May 2008 - Posts

• First Impressions of Web2py

  It kicks ass. There's a video that demonstrates web2py and Google appengine that pretty much says it all.  If you're like me, and you'd rather read a set of step-by-step instructions than watch a video, this is for you.  (OK, this is actually for me when I start a new project 6 months down the road and have forgotten how to do this stuff). Go to the Google SDK Download page. Get the Linux/Other Platforms one.  Doesn't matter what platform you're actually running. I've seen weird stuff happen with the Windows installer. Unzip it wherever you feel like.  (If you're a python geek, feel free to put it in you PYTHONPATH.  If not, it really doesn't matter).  Just somewhere that's convenient for you. Download web2py. I recommend the source code version, because it gives you more flexibility about where to put stuff.  But whatever floats your boat. After you've extracted/installed web2py, run it.  If you're on windows, it's web2py.exe. If you're on linux, the command is "python web2py.py".  It opens a server controller dialog. Enter an admin password. Doesn't matter what it is.  But, if you don't enter it, you won't be able to get to the admin control panel.  Click the "Start Server" button. It should open up a browser window that is looking at its home page.  There's a link to the admin interface (if you gave it an admin password) and another to a set of examples. Go to the admin page.  Build your app there. (This is the fun part...seriously, check out that video).  There are some limitations about what you can do with the models.  These are actually due to limitations in appengine. Don't try to get too fancy, and you should be fine. When you're ready to move forward, update your models.  If you've been sticking to the default sqlite (and I can't think of any reason to change), comment out the first line that imports that.  Replace it with from gluon.contrib.gql import GQLDB db = GQLDB() Stop and close the web2py server. There's an app.yaml file in the root of the web2py distribution.  Update it to reflect your application's name.  Open a command prompt in the folder that contains your web2py directory. Start the appengine server with python dev_appserver.py [web2py directory] Test your app!  (I know that seems like a no-brainer, but some people...) Update the version in app.yaml, and upload with python appcfg.py [web2py root directory]. NOTE: This leaves all the "extra" stuff that web2py installs. Examples and such.  And the root of your app is still the default web2py greeting page.  So the URL to your app is something like http://[appname].appspot.com/[appname].  That may be what you want.  I need to dig deeper and figure out how to change that behavior, because that is not what I want.  (It may be a matter of just replacing the welcome application with your own).  I'll blog about that as soon as I figure that out (unless someone wanders across this and leaves the answer in the comments). It also uses up around 382 files, which could/should probably be stripped down immensely.  The command line stuff should probably be replaced with .BAT files (or whatever's the equivalent on your OS). UPDATE: Massimo Di Pierro was kind enough to inform me that, to make a specific app the "default" one that gets shown as the root, just name it either init or welcome. So far, I've introduced two friends to web2py.  They both had previously tried to get into Ruby On Rails, but they didn't like dealing with all the command line stuff.  They both agree with me that python's more intuitive and simpler than ruby.  They don't really care that it isn't as powerfulhigh-level, because they're really coming from lower level languages like C#. Of course, there are all sorts of other frameworks out there, and web2py seems to be pretty young.  There are things about it I don't like, but that's true about every framework.  I've only begun to scratch the surface with it, but so far I'm extremely impressed. Posted May 13 2008, 08:51 PM by JamesAshley with 1 comment(s) Filed under: coding, Not Dot Net, python, open source

• Initial Thoughts on Google App Engine

  If you haven't heard of Google App Engine by now, you've probably been living under a rock.  I won't try to explain it, or even include any links.  Go check out what google has to say about it: it's intriguing, at the very worst. It's really the first step toward the distributed web as a viable application platform.  Sure, the web's been an application platform for years now.  I ran across an article (sorry, I don't have a link to it) about a year back that  predicted 3 phases of web apps.  Phase 1 was, really, Web 2.0 (whatever that means).  You have rich applications that run on your server (or one that you rent).  Phase 2 was where we've been heading for a while:  you write "controls" that people embed in (say) their MySpace page.  Those controls call into apps that reside on your servers, and the content appears on pages hosted wherever they were added.  Phase 3 is where you get real control of apps that are truly hosted on someone else's servers ("in the cloud," if you will), using their SDK.  Conceptually, maybe not all that different that just renting a shared host and running CGI scripts there. But it's really a huge paradigm shift.  This is the start to that. In a lot of ways, web apps are (for what they are) at the same sort of  maturity level that PC apps were back in the DOS days. Google's doing what Microsoft did with Windows 3.1.  "See how much easier it is to develop on my platform, using my SDK, than it is when you have to worry about things like scalability, database maintenance, proprietary user authorization and authentication, etc, etc."  In a lot of other ways, Microsoft's already done most of this with things like ASP.NET, Active Directory, etc.  And they've taken things several steps further (in the direction they want to go) with Share Point.  Those things are great, if you're part of an IT team writing "enterprise applications."  But, let's face it.  That isn't the fun stuff.  Cowboying out useful apps that people (even if they're just a few of your friends) will actually want to use...that's when software development is cool.  So I applied for a spot as a beta tester, downloaded the SDK, and promptly started procrastinating.  I got my notification that I had a spot in the Beta test yesterday, and I got really excited.  So I actually started messing with stuff and reading the emails I was getting from the google group. Here are some of my initial thoughts:  The basic SDK is nice, and you get most of the built-in python libraries.  But they "sandboxed" a lot of the functionality: you can't access the file system, open a socket, or get to low-level OS pieces.  Shouldn't be that big a deal.  But a lot of the libraries that many people take for granted also get banned from the sandbox, as a result.  Several of the libraries that I've investigated will not work as-is because of this restriction. Python web development has changed a lot since the last time I did anything with it.  Back then, they had just published the WSGI specs (don't know what those are? They don't really matter...except the basic Appengine SDK has a lot of references to this that are really cryptic unless you're familiar with the history). Now there are more web frameworks (reminiscent of Ruby on Rails) than you can shake a stick at. The most popular (because one of the oldest) is Django.  It really appealed to me when it first came out, but it's always felt kind of...meh.  Google has decided to support it as part of its official SDK.  So I looked into it again. I'm still very torn.  It's much higher level than the basic appengine API calls at the root of the SDK, but it still doesn't feel right to me.  And google has gutted much of the "convenience stuff" that makes it so attractive (because of the whole sandbox thing).  I may still decide to go with it, just because it's the default.  That, and Guido was probably the one who chose it.  At least for now. I've also looked into pylons.  Much more to  my taste.  And much more difficult to port/support.  As I understand it, there's currently a limit of 1000 files per app. If you add pylons to your app, it sucks up something like 980 of those. And I don't particularly care for what I've seen of its templating engine.  While I've been doing research, I ran across the cheetah templating engine.  I've been highly impressed by what I've seen so far.  If you do any code generation, it would probably be worth your while to take a look at this. But that would be yet another library to take precious space away from my files. (Okay, space isn't really the issue...but I prefer to have small classes, with small methods, in small files. That just seems easier to organize, to me). Anyway, web2py claims to be working pretty much perfectly. Except that you have to use google's ORM. Which means you can't use their admin tools. But you can develop your site using their ORM and web-based admin center, then switch to using App Engine's ORM to deploy.  I'm really impressed by what I've seen of this framework so far. It seems to have taken several "best of breed" approaches from several other leadin web frameworks and mashed them together.  So I intend to take a closer look at it tonight.   Posted May 08 2008, 07:03 PM by JamesAshley with 1 comment(s) Filed under: theory, code generation, Not Dot Net, python, open source