Since Python 3 is the future, I directly started with Python 3 for my projects. While, There are some frameworks for Python 3, but I’m not a fan of frameworks. I prefer to glue the components myself and write the application – even if it involves more work and boilerplate code, and that’s because of freedom.
When you use a particular framework, you’re bound to a few rules and and modifying the behavior of the rules gets quite difficult, unless you know the framework you’re using from head to tail completely in detail. Half knowledge is very bad.
I knew about CherryPy since Python 2, and when I studied how to write applications using that, it became my favorite framework. CherryPy is basically a minimal framework, or more specifically a server which handles the common headaches that are required to do when writing a web application in Python. The common headaches are like mapping a request into Controller/Action, handling HTTP errors, authentication, etc. No, these tasks are not difficult, but are rather time consuming because of the size of the code involved.
So, why not use a pre-built framework? I’m negating my own statement, eh? Yes. In this case, freedom is not a strict requirement as much as it is required in the application logic, and CherryPy supports Python 3 – Awesomeness.
Continue reading “Getting CherryPy Working With uWSGI”
There’s an old proverb: A little knowledge is a dangerous thing
I love rants. Don’t believe me? Read the title of my blog. So yeah, you’re convinced that I really love rants.
Notice that proverb above? Yes, that’s what I’m going to tell you in this post.
A lot of people who are fans of either Apple, Android, Google or iOS rant a lot about the one they like, and talk illogical bullshit about platform they hate. No, I’m not one of them. I’m not a fanboy specifically. I know the advantages and disdvantages of each OS and most importantly in addition to that, the history of each OS, which is what most of the rant-ers miss – half knowledge.
Though half knowledge while ranting does no harm, but still it’s bad to have half knowledge. Consider one day, if you come across violent person who is a fan of the platform you hate, and has full details about each operating system. You start your rants… I don’t have to tell the rest. Many rant-ers quote text from various sources which are biased towards either of the platforms and the statement makes absolutely no sense!
Continue reading “Things You Should Know Before Ranting About Android or iOS”
Yeah, yet another pointless benchmark about speed of programming languages.
Why I call benchmarks pointless is- The speed of a programming language varies widely with use cases.
Language X might be good at executing loops, while language Y might not be.
Additionally, you have to take into account the time spent in developing the programs.
Interpreted languages like PHP, Python, Ruby make a developer’s life very productive and easy, while it may not be for a C or C++ developer.
I am not a fanboy of any language, I just use the language which suits the requirements perfectly.
The languages I’m comparing in this benchmark are C, PHP, Python, Ruby.
Continue reading “A Benchmark About Speed of Programming Languages”
This post is about configuring Trac and Git to work together properly. As you might be knowing, Git is a DVCS – Distributed Version Control System and Trac is a project management system. By default, Trac supports SVN, but there are plugins for Git and Mercurial. I don’t know if there are plugins for other repositories like Bazaar, etc.
In the default configuration in Trac’s Git plugin, the repository is not cached and setting
repository_sync_per_request to blank doesn’t stop Trac from syncing repostiories on each request. This is a big performance disadvantage and can big a real big trouble if you have lots of repositories with quite a lot of commits.
Continue reading “Trac and Git: The Right Way”
SQLite is probably the world’s simplest Relational Database Management System. Basically it’s a C library which can be embedded in programs easily. There is no server/client mechanism, the database is a single file. For small work loads, it often makes no sense to use a big RDBMS package like MySQL or PostgreSQL, unless of course you need the special features they provide.
So, I came across this situation where I need replicate SQLite database. The problem arised because, data redundancy was needed across multiple servers and the program in question was supporting SQLite, MySQL and PostgreSQL; but one of the servers had only workload for PostgreSQL database and installing MySQL for the small amount of data the program handled wasn’t sensible. The other two servers had pure MySQL workload. Also, the updates needed to be propagated. So there is the deadlock.
Continue reading “SQLite Replication”