And, yes, undoubtedly, I’m going to fosdem next year (2009).

Therefore, the next banner will be present on the website during all that time.

Be there, or stop visiting codercpf.be!

As I’m all about python, and pythonic is the way I speak any coding language, I had a challenge in finding a way to dynamically implement new variables in a class.

Unlike python, in which this is very simply done by:

class MyClass:
    def __init__(self):
        self.newvar = 'value'
        self.newvar2 = 'bla'

It’s quite the challenge doing something similar in PHP. In fact, even after finding a partial solution, it’s plain _impossible_…
One way, though, to make it seem like you succeeded in that fact, is by using the __get and __set function definitions in PHP. Quite similar to __getitem__ and __setitem__ in python. Especially in its implementation.

The solution

Now, as to explain whatever I was brabbling earlier into clear, simple code, and testing code:

class MyExplainerClass {
    private $data;

    public function MyExplainerClass() {
        $this -> data = array(); // Initialization
    }

    public __get($name) {
        if (array_key_exists($name, $this -> data))
            return $this -> data[$name];
        // Here you can put debugging, error showing, etc...
    }

    public __set($name, $value) {
        $this -> data[$name] = $value;
    }
}

$myTester = new MyExplainerClass();
$myTester -> newvar = 'value';
echo $myTester -> newvar; // value

Now, that’s about everything here to explain. I think it’s clear enough for even the simpelest out there.

So, you’re here on some quest to solve an issue where you do any amount of insert queries through MySQLdb but it doesn’t appear in the database?

Well, I had exactly that issue. Took me ages to figure out why after moving an app to another server (with by design the same database, except for a small difference explained later), the app didn’t insert anything (!!), but didn’t give any errors either.
Thinking to myself: “Weird stuff, can’t be happening!”

So, I went on that quest myself.

Solution is quite simple:

import MySQLdb
db = MySQLdb.connect([...])
c = db.cursor()
[ Couple of insert statements ]
db.commit()

This commit is the key. The reason you’re having the issue is probably because you’re using innoDB as the database engine…

So, as the title says, we’re going to install trac on apache using mod_fastcgi.
Now, before we get off, some explanation on why I write this:

As it is, I tried to follow the documentation on the official trac website. But it was unclear, and made me very confused. In the end, someone had to tell me how simple it was before I wanted to believe it in the first place…

In this small post, I’ll assume you have a trac environment configured.

Two steps

Yes indeed, just two steps are required. In here, I’m going to assume you either have a website running already, or you are going to create a virtualhost for trac.

In the end, I’ll post my own virtualhost, so that everyone can reference on that.

Step one

First, you have to “deploy” the trac environment. This is done with the following command:

trac-admin /path/to/env deploy /path/to/apache/htdocs

Now, one thing to really keep in mind is that you cannot deploy in the env directory (or by my experience anywhere near it) It’s best to simply use the /var/www/htdocs most apache setups use.

Step two

Now, we configure apache. In the virtualhost section you want trac to run in, you add the following:

ScriptAlias /trac /path/to/apache/www/cgi-bin/trac.fcgi/

The trailing slash is really important, otherwise the cgi app won’t see the page as argument!

Also, you can alias straight to / if you want, it will work too (if you don’t share this virtualhost with another app)

Note: If you’re running (or going to run) multiple trac instances through apache, you should go to /path/to/apache/htdocs/cgi-bin/ and edit trac.fcgi to change TRAC_ENV to TRAC_ENV_PARENT_DIR:

os.environ['TRAC_ENV'] -> os.environ['TRAC_ENV_PARENT_DIR']

Test it

Albeit this is not the third step (there is no third step), it’s best to take a look and test. But you should see the trac pages coming up pretty quickly, and you should be pleased, for it is the simpelest thing to configure.

As I promised, this is my own virtualhost, just to make sure people might learn from it:

<VirtualHost *:80>
        FastCGIExternalServer /home/user/project/fcgi.fcgi -socket /home/user/project/scgi.sock
        ServerName project.com
        DocumentRoot /home/user/project/
        Alias /media /home/user/project/media/
        ScriptAlias /trac /var/www/htdocs/cgi-bin/trac.fcgi/
        RewriteEngine On
        RewriteRule ^/(media.*)$ /$1 [QSA,L,PT]
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_URI} !^/trac.*$
        RewriteRule ^/(.*)$ /fcgi.fcgi/$1 [QSA,L]
</VirtualHost>

Note that this virtualhost is also hosting a django config, and I have added a RewriteRule to make sure /trac isn’t handled by it. Which was a huge stumble point before, and therefore I thank the great people at the #trac channel on irc.freenode.net !

As always, any comments, improvements, or even thanks are welcomed!

Today I was configuring apache(2) under mod_fastcgi to get my django project working on it. It was requested since the testing would go on a similar-to-deployment method.

So, I followed the guides at djangoproject but, as it seemed, I had some issues. Some were my own problem, some were not.
After fixing them, I decided to write a little “tutorial” to help other people perhaps having the same issues.

First things first

Before digging in to this tutorial, I advice trying to do the guidelines of django itself. In the end, if you follow as strictly as possible, it should work.
What will be discussed here will look very (and I mean very) similar to the guidelines of django, but with some notes on what I met on the process.

What is assumed?

During this, I’ll just simply assume you’ve got apache, and tested it to work (the way you installed it), I’m not going to explain how to install apache in any way, it’s useless, pointless, and there’s a whole bunch of tutorials covering it way better than I possibly could! GOOGLE it if you don’t have apache yet!

Step one.

So, as for the tutorial itself, we’re going to start of with running your django project in fcgi modus. As it is, the basic usage is very simple, and you can’t possibly go wrong in this.

Got from the official documentation:

./manage.py runfcgi [options]

Where [Options] is mandatory. The simplest way would be to use the socket option (as I’ll describe below), and a pid file is highly recommended!

In the end, you might want to configure your own protocol too (django supports all protocols supported by flup. And I chose for scgi (for unknown reasons really…)

So, knowing those things, the basic best-use would be to use the command:

./manage.py runfcgi socket=/path/to/socket/file pidfile=/path/to/pid/file [protocol=your_protocol]

To make things easier, I put those things straight in my project directory. Although one might opt-in for the approach of having a subdirectory, or using a completely different directory.

However, to start, which will help anyone having trouble setting things up properly, you should try to stop deamonizing the script, eventually you’ll see whatever happens…

To do so, just add daemonize=false to the string of options. Note that we’ll only use this during the test of the setup, if you don’t have any issues, I even wonder why you’re still reading this…

One might also be interested in auto-starting some script, but I’ll leave that shizzle up to you, although I strongly recommend, I can’t cover most auto-start script here (and since I’m used to archlinux, it was a hassle to do so on debian!)

Apache is next.

So, we don’t have to look back to the project anymore, we’re going to start of configuring apache.

Now, on this, I find the documentation of django a bit unclear, but depending on your OS, you’d be editing httpd.conf (or similar, e.g. on my debian it was called apache2.conf)
For clarity I’ll just keep refering to httpd.conf from here on!

After (obviously) installing and activating mod_fastcgi, you’d have to get one line in the httpd.conf file to enable the apache server to communicate with your project.

httpd.conf:
FastCGIExternalServer /path/to/fcgi/file -socket /path/to/socket/file

NOTE: The fcgi file can exist, but it is no requirement.
NOTE2: If you’re later on testing get “Permission denied: FastCGI: failed to connect to server blabla: connect() failed” you’ll need to make sure the user apache uses (mostly www-data) has access to the fcgi file. The simpelest way to solve this is a chmod 777 /path/to/fcgi/file

Next thing would be to configure your website. Note that here you’ll have to use the proper syntax to get your /media/ online. I used /media/ too for my own media files (in the end seeing that it isn’t the proper/best method, I’ll change that when I got the guts)

httpd.conf:
<VirtualHost 0.0.0.0>
  ServerName example.com
  DocumentRoot /path/to/document/root
  Alias /media /home/user/python/django/contrib/admin/media # Note that this may differ per setup
  RewriteEngine On
  RewriteRule ^/(media.*)$ /$1 [QSA,L,PT] # This one will NOT get django to deliver the media files
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteRule ^/(.*)$ /fcgi_file.fcgi/$1 [QSA,L] # Note that you'll have to use the proper filename
</VirtualHost>

To end

Now, restart (or start) apache, and best tail -f the error file (just in case), pay attention to your (if you did what I suggested) non-daemonized django project. If nothing happens, and you can visit your website without an 500 internal server error, or anything similar, you can get the daemonized django project in the running!

Congratulations, you just configured and installed apache + mod_fastcgi to use in your django project. Next would be to actually get things running the way YOU want it.

Before I leave you guys to never visit me again, I’d like to thank the guys at irc.freenode.org#django for the help, and the django developers for getting such a great framework online!

With the past project, I’ve been using django all the way.
Given the requirements for that project, I judged that we were going to be needing a lot of AJAX, and I immediatelly started looking around for ways to do this. Luckily, it was found pretty quickly.
The is_ajax method

Conveniently enough: django provides a method inside the request, is_ajax, it’s pretty straight forward to  what I was looking to: A method to figure out simply and quickly whether or not a request is indeed originating from my AJAX platform.

There are -however- several items to take in account when using is_ajax:

1. is_ajax checks the HTTP_X_REQUESTED_WITH header to varify the source to be AJAX or not. This is being used by most of the javascript frameworks, including prototype (which I opted for).
2. In the current form, the CSRF (Cross Site Reference Forgery) middleware won’t work with AJAX, I have submitted a patch for that, but it has not yet been included in the svn. If you are using (or going to use) the CSRF middleware, you might consider changing the source.

Using is_ajax

To use is_ajax inside your view is a very straight forward and easy thing. However, considering several items, I would advice several things:

1. I never use AJAX GET requests, ever. Because of that, I’m always checking whether or not the request was indeed a POST request. I advice using the same method (only allow one of both per page you’re requesting). Take in mind though the common sense: POST should be used when you’re intending to change values, GET whenever you’re just going to get some data and return it (get_or_404 e.g.) Even though we’re talking AJAX, we should still be on guard.
2. NEVER, EVER trust anything coming from an AJAX request. Albeit you should never ever trust any request, I find the AJAX requests still more dubious. Especially since people are discovering ways to misuse the trust in AJAX more quickly. As a rule, anything coming from outside should be checked, and anything coming from the inside should be looked at in suspicion.
3. When you’re using AJAX in a user authenticated area, always check for that user. It might sound as if I’m saying stupid things, but even though you expect the user to be there (it being a user area after all), it might just as well be something else.

Those things being pressed, this is how I use is_ajax fully:

if request.method != 'POST' or not request.is_ajax() or not request.user.is_authenticated():
    return HttpResponseForbidden('')

Simply put, it follows my method of thinking. First of all, the request should be POST, than, it should be an AJAX request for this function.
Those are the 2 basic “technical” items of the request. The third being the user authentication check, is actually only because it’s more secure and I need to use that user data later on.

If at any of those three the check fails, and goes to the return statement below, I follow the correct way of webdevelopment in telling the user/program the request is forbidden. Because it is, since it didn’t go through the checks. I was tempted to return a 404 document, it being a bit more cryptic, but it won’t change a darn thing after all.

As this concludes my little lecture, I’m going to let you guys play with the django framework some more!
References to the things I spawned at your face:

• Request Response documentation
• CSRF middleware
• The CSRF + AJAX ticket

While on my quest for a proper framework, which in the end I would like to use all the time, I stumbled upon django.

“Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design.”

This is how they describe the project. And quite correctly that is.

While trying to figure out if I would like to use the framework, and interested to use the power of python together with web development, I got my hands on a project, which would be using django all the way.
Knowing no django at that point, I started learning the framework, and amazingly enough, the day thereafter I started the project, and everything worked from the start, currently, the project houses 2 apps, about 5000 lines of code, and everything is still working fine, clear, etc…

As I am implementing the new template system, I found that I spent more time using the version control than coding the actual project (!)

Why this post was started is simple: As from this moment, I’ll be writing frequently about django, and python. Because those are the things that my interests catches the most at the moment!

So, the android stuff hasn’t been posted often in the past year. Granted, the website did get most of its traffic because of these posts, but not quite the traffic I wanted, and I only wish to write about things I know sufficient of.
Android is developing so fast, and on so much different items, that it is becoming nearly impossible for only one person to keep track of it all, without spending a full-time job on it…
Does that make me less interested in Android? NO, it’s just so that I’m no authority on the subject, and there’s currently a whole bunch of websites/blogs doing a better job at reporting the events than I ever did.

Anyhow, this is the era of python in codercpf.be, I hope you guys are ready for it!

Until next post, CPF_

PS: As some of you (probably no one, except for google bot) noticed, I’ve changed hosting. Losing a lot in the progress (I hate moving!)
I’m currently being hosted at www.webfaction.com , which also allows for django, pylons, etc… projects to be hosted on the site!
Therefore, please expect some of my projects online here, and as it is, I’m going to make you guys some projects you just can’t ignore!

Hi @ everyone and nice to be somewhat back.

The site has been through some movement, and thanks to that, the previous loadFoO was lost in the process.

This time though, I’ve got a design from pikanai.com, called Simple beauty. I ported it on wordpress as usual, and if any of you wish for the files, please ask. I will make sure you get them ;)

Also, please give the opinion, it’s highly appreciated.

Anyhow, this’ll be my leave for a while again.

PS: Keep It Simple, Sexy ;)

For today (and of course the previous days of inactivity) I’ve got a quote, which I really liked:

“Windows is a 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can’t stand 1 bit of competition.”

Beat that!

CPF_

Sorry for the late idleness, I’ve been quite busy elsewhere.

Nonetheless, there’s some nice work going on with the android platform, again. This time someone has published his current work status in creating a Netbeans plugin to emulate the Android OS.

Screenshots are found here: http://picasaweb.google.com/joerg.ruethschilling/AndroidPluginForNetbeans

I’m definitely using that one when it’s out there, I’m a Netbeans user myself, so working with eclipse isn’t really my style (works though).

UPDATE
As it is, I just read that the android plugin for netbeans will never come to an end. Apparantly,  google licensing prevents the SDK to be used in another IDE than eclipse.

I’m sorry to everyone, but that’s just the way it is. Too bad though, because android on netbeans would’ve been really fast and powerfull…