September 8, 2010

Why I didn't switch from jQuery to ExtJS after all

A while back, I wrote an article about why I was switching to ExtJS from jQuery. This remains one of the top ten pages on the site, despite the fact that I never really did switch. Checking it just now, I am certain that it is the most heavily commented article on the site.

The fact is that I started to switch, did a site or two, and then I quickly changed my mind.

There are four reasons I didn’t end up switching from trusty jQuery. Size, familiarity, purpose, and license.

[Read more...]

Technorati Tags: , , , ,

Amazon Payments for Satchmo

I’m not sure how I missed it before, but PayPal has a new competitor in Amazon Payments.

I applied this evening to the beta “Flexible Payment Service” so that I can develop a plugin for Satchmo, using Amazon Payments.

It looks really interesting. The base features will be a snap to do in python/Satchmo, of course. But the other features are quite intriguing. I’m particularly interested in the the ability to:

Create “Payment Instructions” to define conditions and constraints desired for a given transaction, and programmatically obtain payment authorizations or “tokens” that represent these Payment Instructions from customers.

And of course I’m also interested in the multiple and recurring payment options. But what’s this? Aggregating micro-payments using pre or post-paid systems. Nice! This is what I was hoping Google Checkout would be.

I went ahead slapped a little “pay now” Amazon Payments button on my Invisible Castle gaming site. It is just to lower the barrier to paying me, and to test out how well it works. It isn’t micro payment, recurring, or a split-payment, so it isn’t enormously-geeky-great, but it is money after all. Hehe.

[tags]webservices,amazon payments,paypal[/tags]

Sqlite3 made Safari Crash

CrashShort story: upgrading SQLITE3 makes Safari crash in OSX.

Using Sqlite on several systems recently, I decided to upgrade the installed Sqlite on my Macbook Pro. Otherwise I kept running into version incompatibility problems between the Linux systems and my Mac.

Compiling was easy enough, but by habit before I installed the new libraries, I made a backup of the current libraries. Good move.

Since upgrading, I noticed that several apps started crashing on start. Safari & Ecto were the worst offenders. This morning, I finally had enough and began digging into the root cause.

Aha! Sqlite3 library errors. Seems the Safari engine needs Sqlite the way it was installed. A quick rollback and Safari and my old friend Ecto are once again happy. Annoying for my cross compatibility needs, but I’ll just have to figure out how to make the old and new ones run side-by-side.

p.s. I’m back from vacation, and regular posting will now resume.

[tags]crash,safari,sqlite[/tags]

SQLAlchemy = Another great SQL Frameword

Surgical ToolsJust a few days ago, I was talking about how much I enjoy PySqlite, and now I’ve found another great tool for my SQL war chest. SQLAlchemy

I am already using it for another part of a big multi-database reporting project. The fun part for me is that it is more modular and less demanding of structure than SQLObject, so I can actually use its superior raw SQL connection and marshalling capabilities for manual report queries, while continuing to utilize my SQLObject enabled object model.

Very sweet, and very quick to get going on my Mac development and Linux deployment environments. I’m currently collecting data from three different databases (SQLite, PostgreSQL, and MySql) on five different servers. This is a killer app for me.

I’ll be exploring its object-relational capabilities soon, but I am already very fond of the framework, and how lightweight it feels.
[tags]python,sql,sqlobject,sqlalchemy[/tags]

Discovered the killer combo of Pysqlite and SQLObject

Light BulbAt work, I’m doing a bunch of data acquisition on various machines outside the firewall. I think I’ve hit on an absolutely great combination of Python technologies to do this in a really manageable and scalable manner.

The design constraints:

  • No long-running processes. These are heavily loaded boxes. The data acquisition will run via scheduled cron jobs.
  • No new ports open. I can’t run Mysql on these boxes.
  • No drilling back from these servers into the corporate network. So I can’t run mysql inside and connect from the outside.

The plan

  • Each remote box will run a small python app on a scheduled basis, writing its data to a single file.
  • A "gatherer" system inside the firewall will retrieve the files from all remote machines on an hourly basis.
  • On acquisition, the remote files will be removed.
  • The gatherer process will then merge the remote data into a master Mysql database for reporting.

The technologies

  • PySqlite: will provide access to an on-the-fly generated database file on remote machines.
  • SQLObject: can talk to both PySqlite and Mysql. I simply define the object model using its scheme, and it will happily generate the tables for me in both Sqlite and Mysql. Writing the merge process was the trickiest bit, but it only took a few hours to write and test.

Conclusion

This was an extremely fast development path. I was all the way from concept to deployment in just three days, and I didn’t even know anything about SQLObject or Sqlite at the start.

Contrast that productivity to Java, where a similar project would take at the minimum a couple weeks, and you start to see why I think that Python has become the secret weapon in my developer toolbox.

[tags]python,sqlite,pysqlite,sqlobject[/tags]

Magic Removal Success!

Classical GuitarI’m pleased to report that the Django magic removal branch is now much easier to use. It feels stable, the docs are getting complete, and I see now that the branch has now been officially merged to the head.

My magic-removed code works great, and is passing all its tests with flying colors. Total time taken for 3 apps was approximately 4 hours. The only real pain was in updating the database. I feel certain I could have made it work, but I took a shortcut and simply reset the whole thing.

manage.py syncdb is sweet!

[tags]Django,magic-removal,python[/tags]

Prototype library – dissected

Surgical tools Thanks, Jonathan Snook for creating such a useful (and gorgeous) set of printable reference sheets for the excellent Prototype library for Javascript.

I use Prototype to support almost all my Javascripting on the net, both at work and on personal projects. It is a great library, and this reference just makes it clear how clean and well laid-out the library actually is.

[tags]javascript,prototype,reference[/tags]

How to install Cheetah on Dreamhost

CheetahsInstalling Cheetah on Dreamhost’s shared servers is actually a snap, if you have access to a Linux development system. All you have to realize is that the servers are Intel-based Linux systems, Python setup utilities know how to build “dumb” distribution, and that python doesn’t care if you use symlinks to trick it.

Building Cheetah

  1. Skip this step, if you like, by downloading my precompiled Dreamhost-friendly version.
    Download: Cheetah-1.0.linux-i686.tar.gz
    (MD5 Signature: 5e64240ae6dd7eb0ffe92fdde61fe5ea)
  2. To build, go to a Linux computer, preferably Debian, with Python 2.3 installed.
  3. Download Cheetah. I’ve tested this with 1.0. I don’t know about 2.0, probably the same steps would work.
  4. Unpack Cheetah in a temp dir.
    tar xzf Cheetah-1.0.tar.gz
  5. Compile a “dumb distribution”
    cd Cheetah-1.0
    python setup.py bdist_dumb --relative
  6. Copy the compiled distribution to Dreamhost. You’ll find it at “dist/Cheetah-1.0.linux-i686.tar.gz”

Installing Cheetah

  1. Unpack the compiled Cheetah package in some directory. I’ll assume you are going to unpack it in your home directory.
    tar xzf Cheetah-1.0.linux-i686.tar.gz
  2. It will unpack into two directories.
    • lib/python2.3/site-packages/Cheetah — the compiled site packages
    • bin — Cheetah compiler binary
  3. Now, you need to edit your ~/.bash_profile and add a couple lines:
    PATH=$PATH:$HOME/bin
    PYTHONPATH=$PYTHONPATH:$HOME/lib/python2.3/site-packages
    export PATH PYTHONPATH
  4. Now, add the environment variables to your current session.
    source /.bash_profile
  5. At this point, Cheetah should work! Congratulations!
  6. If it compiles all right, but doesn’t work via the web, then you need to make sure your Cheetah dir is available from your web-context pythonpath. The easiest, hackiest, fastest way to do this is to simply make a symlink to Cheetah. This fools Python into seeing the “Cheetah” module in the same place it sees your project files. My domain has its Python cgi files right in the root, so I just did it like this:
    cd ~/mydomain.com
    ln -s ~/lib/python2.3/site-packages/Cheetah .

Please let me know how this works for you, I’ll attempt to help you out if you run into problems.

[tags]python,dreamhost,cheetah,cheetahtemplates,howto[/tags]

Prototype modification to fvlogger

logging is fun with the right toolsfvlogger.js is a fine logging system for Javascript, but when you are already using Prototype.js, it unnecessarily duplicates a lot of functionality. I’ve forked the original code to “fvlogger 1.0.proto”, removing this duplication. In addition, I’ve added a sweet “add the logger to the page” function to the script. The end result is much smaller and cleaner looking than the original, I think.

This script is based on fvlogger 1.0, available from Five Volt Logic. It requires prototype, and if you want to use its auto-insertion features, it requires Behaviour.js as well. If you aren’t already using the Behaviour library, you should. It will revolutionize your use of Javascript, fully separating user interaction from markup. Most times I use it, I never have to use a single line of inline javascript at all. That is incredibly liberating!

If you want to use Prototype 1.3.x, you will also need to load a few functions borrowed from “the future”, which I’ve helpfully included as “prototype_future.js”. Just look at the test page in the zip, and all should be clear.

Download protologger-1.0.zip and let me know what you think.

[tags]javascript,libraries,prototype,logging,fvlogger,behaviour[/tags]

Django encourages Flow

Django is one good web framework. It is the easiest portal into programming “Flow” I’ve found in ages. Programming for Django rapidly sucks me into an extremely rapid and engaging code-test-next cycle.

Flow = Productivity

There is an often quoted statistic in the programming world. A good programmer will outperform a mediocre one by a factor of 10:1. These numbers are pretty accurate in my experience, and I’ve long considered the reasons why this is so. My observation is that great programmers are not necessarily immensely more intelligent than their slower companions, rather they are more talented at entering Flow.

If my theory is correct, then anything which enables the programmer to get into this state is to be encouraged. The work done in a Flow state will be done much faster and with fewer errors than any other work. Perhaps more importantly for the programmer, it will be more enjoyable.

But what is Flow?

Mihaly Csikszentmihalyi has written two books about this topic, Flow, the Psychology of Optimal Experience and Finding Flow. I think the best summary of the experience is found in the first paragraph of Chapter 4 in Flow.

We have seen how people describe the common characteristics of optimal experience: a sense the one’s skills are adequate to cope with the challenges at hand, in a goal-directed, rule-bound action system that provides clear clues as to how well one is performing. Concentration is so intense that there is no attention left over to think about anything irrelevant, or to worry about problems. Self-consciousnes disappears, and the sense of time becomes distorted. An activity that produces such experiences is so gratifying that people are willing to do it for its own sake, with little concern for what they will get out of it, even when it is difficult, or dangerous.

How Django encourages Flow

  • It allows a Python programmer to use clear rules to create a data model and to apply it to the task at hand. It doesn’t require a lot of context-switching between Python and SQL, which helps maintain flow.
  • It breaks down the problems into clear, testable chunks, which means that one is not “programming out on a limb” for a long while, like I often find Java encourages me to do.
  • It uses Python to configure Python, which is a refreshing change from the increasingly XML-heavy frameworks found elsewhere, especially in the Java world. Not only is that “refreshing”, it is one less context-change that is likely to drop the programmer out of Flow.
  • It automatically produces “the boring parts” of the application. Unenjoyable drudgery such as creating admin pages is one sure way of dropping the programmer from the Flow state.
  • It is so quick to program in, problems are solved so rapidly, that it encourages you to do “just one more part”, thus making time fly by.

[tags]flow, python, django, webapp, productivity[/tags]