Freedom of choice in architecture design
I’ve been part of many projects where choice of language, frameworks and libraries were imposed by the client strictly. This became so natural that even for my own projects I used to look at designing them around single language (ie. Python). Usually JavaScript creeps here and there as well regardless it seems these days of what you are developing: web app (obviously!), data base views (think: CouchDB), game (Unity3D), desktop apps (Titanium/others?).
Time shows that the saying “if the only tool that you have is a hammer, everything starts to look like a nail” is absolutely correct. In every system design the right tools should be used for the job. This is obvious! – you may think. Sure, but how often did you end up anyway thinking in categories of single language?
To be really flexible think of mixing and matching different languages for your projects.
Node.js is maturing and becoming serious contender when it comes to writing web apps. Throwing Objective-J to the mix may give you huge productivity boost. Using Python on the backend to utilize its great amount of libraries to glue your app with whatever you may want or wish for or to handle some more advanced logic. And Erlang for the parts of your system that need concurrency and its async nature (ie. for streaming). There’s four languages right there! And who is not to say that you’ll want to boost some performance with C or C++ modules for Python, Erlang or Node.js in the above scenario.
Unfortunately not every project owner will give you such freedom. But it’s your task, as a software architect/lead programmer/etc to rationalize use of every and each tool at your disposal.
Time is most precious asset in every project – using right tools for the job means better productivity so delivery faster.
Read MoreGeneralization leads to unnecessary complexity
Every good programer likes the code to be clean and well organized. That leads very often to the temptation of making the code generic. Object Oriented designs are pushing us towards that every day, so it’s also very natural to start making wrappers, factories and interfaces. Use of inheritance encourages code re-use and generalization.
Unfortunately very quickly this can lead to the unnecessary complexity anti-pattern. When you’ll start seeing that navigating through your code takes you on a journey that resembles a maze with many twists and turns – you’ve hit this problem.
Getting there is usually very innocent at first. Making function size small and readable is always a good idea but it can be the first step that will lead you to a spaghetti code. When working on a complex problem and splitting it into smaller digestible chunks it’s important to keep the high level of data flow and processes in mind.
Read MoreSolving problem with FB.Connect.showFeedDialog() empty popup in Firefox
I’ve just found out a solution to an issue that bogged me for last few hours and I just like to share it here… Basically if you’re developing an Facebook Connect app and using FB.Connect.showFeedDialog() inside a callback from some other AJAX call you may notice that under Firefox you may get a blank popup box from Facebook.
Without going into more details, as no sources I’ve seen managed to get into the real reasons why this is happening, here’s the solution:
Wrap your FB.Connect.showFeedDialog() call in setTimeout callback, like this:
setTimeout(function(){
FB.Connect.showFeedDialog(template_id, params)
}, 0);
Found the solution to this here.
OpenMetaverse (formerly known as libsecondlife) Bot in IronPython
The OpenMetaverse documentation seems very dire in any up to date examples, especially in mono and non-existent for IronPython.
After few minutes of playing around with it let me share with you an example how to start off with making your own bot in SecondLife using OpenMetaverse lib and IronPython:
First download and install Mono and OpenMetaverse( just follow the official instructions here )
When you finish this step you should be able to go to the bin/ directory within the folder where you’ve unpacked OpenMetaverse and see many .exe files. If you’re a Windows user just try to play around with them, if you’re on MacOSX or Linux try running them from the console by typing: mono program_name.exe
That’s the basic requirement. If you’re able to get pass that point you’ll need to install IronPython.
Try running command ipy from your console, you should see:
$ ipy IronPython 1.1 (1.1) on .NET2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. >>>
Now the fun bit. Writing the actual bot.
Let’s follow the official example which logs into the SL grid, says hello and exits.
import clr
from System import *
from System.Text import *
from System.Collections.Generic import *
clr.AddReferenceToFile("OpenMetaverse.dll")
from OpenMetaverse import *
first_name = "John"
last_name = "Doe"
password = "pwd1234"
client = GridClient()
def Network_OnConnected(sender):
print "I'm connected to the simulator...\n" # or Console.WriteLine("I'm connected to the simulator...")
client.Self.Chat("Hello Grid!", 0, ChatType.Normal)
Console.WriteLine("Now I am going to logout of SL.. Goodbye!") # or print "Now I am going to logout of SL.. Goodbye!\n"
client.Network.Logout()
client.Network.OnConnected += NetworkManager.ConnectedCallback(Network_OnConnected)
if( client.Network.Login(first_name, last_name, password, "My First Bot", "Your Name")):
print "Logged in\n"
else:
print "I couldn't log in, here's why: %s" % client.Network.LoginMessage
Django model fields in many languages
So I found myself in a situation where I needed to have multilingual support for the DB in Django. i18n does a great job for static messages, but what about all that dynamic data, ie. news in multiple languages. Sure you could create a column per language you want to support but that’s an awful waste on the table, plus when you want to start supporting additional languages you have to alter the table to add columns — not a best, and definetly not the most user friendly way.
Another way around the problem is to create separate table for each table that requires multilingual fields. Every translation table would have a ForeignKey to the parent table and consist of all the fields that need to be in a specific language plus either a field or ForeignKey to a table that has the language code (for queries/identification which language is used).
I’ve created
django-multilingual-model to do just that and make it easier to use/query such tables.
Here’s an example:
class Language(models.Model):
code = models.CharField(max_length=5)
name = models.CharField(max_length=16)
class BookTranslation(models.Model):
language = models.ForeignKey("Language")
title = models.CharField(max_length=32)
description = models.TextField()
model = models.ForeignKey("Book")
class Book(MultilingualModel):
ISBN = models.IntegerField()
class Meta:
translation = BookTranslation
multilingual = ['title', 'description']
lang_en = Language(code="en", name="English")
lang_en.save()
lang_pl = Language(code="pl", name="Polish")
book = Book(ISBN="1234567890")
book.save()
book_en = BookTranslation()
book_en.title = "Django for Dummies"
book_en.description = "Django described in simple words."
book_en.model = book
book_en.save()
book_pl = BookTranslation()
book_pl.title = "Django dla Idiotow"
book_pl.description = "Django opisane w prostych slowach"
book_pl.model = book
book_pl.save() # now here comes the magic
book.title_en
u'Django for Dummies'
book.description_pl
u'Django opisane w prostych slowach'
Read More
Non-blocking use of Django models API
If you’ve ever used Twisted framework and got through the first a bit hard learning curve, you most likely fell in love with it.
And if you’ve every used Django you most likely thought — isn’t there a way for it to run faster and in non-blocking fashion — especially if you want to write a web application that integrates other protocols.
One major block on the road is the DB models API which I’ll focus on now.
So let’s say you’re considering to use Django’s models in Twisted application.
Of course this does not automagically makes your code non-blocking. Just allows your blocking DB code to run without affecting Twisted’s reactor (too much). Be careful not to defer to thread too often!
from twisted.internet import reactor, threads
from django.core.management import setup_environ
import settings
import string
setup_environ(settings)
from foo import models
def getUser(user):
print "Hello %s %s" % (user.first_name, user.last_name)
def handleError(e):
print "Error %s" % str(e)
deferred = threads.deferToThread(models.User.objects.get, username='yazzgoth')
deferred.addCallback(getUser)
deferred.addErrback(handleError)
reactor.run()
Read More
Member of
