Posts Tagged ‘open source’

How to Install MySQL with Fabric

Saturday, May 22nd, 2010

I just want to share a small fabfile snipplet that installs mysql-server package on a Debian machine if it’s not already installed. Actually it should have been quite straightforward; just issue an apt-get command, right? But during configuration it displays a curses dialog for MySQL root password. This of course blows your automated configuration plans. We will seed this value to debconf database to avoid this dialog.

First let’s have a look at the supporting code:

from __future__ import with_statement
from fabric.api import *
from fabric.utils import warn

def apt_get(*packages): sudo('apt-get -y --no-upgrade install %s' % ' '.join(packages), shell=False)

Our apt_get fabric command issues apt_get install that answers yes to all questions and does not upgrade if the requested package is already installed. Now let’s take a look at the main command that installs mysql-server:

def install_mysql():
    with settings(hide('warnings', 'stderr'), warn_only=True):
        result = sudo('dpkg-query --show mysql-server')
    if result.failed is False:
        warn('MySQL is already installed')
        return
    mysql_password = prompt('Please enter MySQL root password:')
    sudo('echo "mysql-server-5.0 mysql-server/root_password password ' \
                              '%s" | debconf-set-selections' % mysql_password)
    sudo('echo "mysql-server-5.0 mysql-server/root_password_again password ' \
                              '%s" | debconf-set-selections' % mysql_password)
    apt_get('mysql-server')

First we want to make sure mysql-server is not already installed. For this reason we issue dpkg-query --show mysql-server. Note that if this command fails then mysql-server is not installed and we can proceed otherwise we want to return. We hide the ugly error messages by running our dpkg-query command within a settings context:

with settings(hide('warnings', 'stderr'), warn_only=True):
    result = sudo('dpkg-query --show mysql-server')
if result.failed is False:
    warn('MySQL is already installed')
    return

The rest of the code is pretty straightforward. We prompt to the user running fabric for the root password and seed its value twice into the debconf database.

sudo('echo "mysql-server-5.0 mysql-server/root_password password ' \
                            '%s" | debconf-set-selections' % mysql_password)
sudo('echo "mysql-server-5.0 mysql-server/root_password_again password ' \
                            '%s" | debconf-set-selections' % mysql_password)
apt_get('mysql-server')

Finally, having finished our little dance, we install mysql-server. I hope this helps some automated deployment believer out there.

Bookmark and Share

Why Not To Localize Community Support

Friday, April 16th, 2010

If you are reading this, you know English. I would like to pose a question before we go any further; would you prefer community support in your native language over what international community offers?1

By community support, I mean free software support provided by the user community. Every successful project has some form of communication; mailing lists, forums, IRC, wikis, etc. And the preferred language is almost always English. Simply because you can reach more people. People who can use your code. Who can test it, file bugs, send patches, etc. It is the logical thing to do. But in the spirit of freedom, I think nobody should be forced to use a certain (natural or programming) language for something they have created.

Real Communities

I think having local communities is a great idea. I don’t know, because we don’t have any in Türkiye2. So I am just guessing they should be cultivating and fun at the same time. We do have many local pseudo-communities though. There is some activity, people come and go, some of them stay much longer than the others. But they never progress towards a community. I think this is because they make the fundamental mistake of localizing community support. They translate documentation intended for highly technical people and create new channels that no advanced user will bother to participate. In short, they attempt to sidestep the language barrier.

If want to be a programmer you need to know English. It is not optional. It is not a requirement of being a good programmer. You are at most an excellent script kiddie without proper English skills. Obviously, knowing perfect English doesn’t make you a great programmer instantly. It will increase the resources you can access dramatically, though. And most importantly it will give you the chance to know more about what you don’t know. Stay in your little world to play with your mates who know just as little as you do and you will never improve.

A Foolish Endeavour

Some people, who spend time with these pseudo-communities, know English well enough. They are probably acting with good intentions when they provide support in their native language. But they are actually wasting their time. Having been solved one specific problem doesn’t make the other person a better programmer. On the contrary they are giving local users another reason to avoid solving the real issue. The function of a community should be supporting each member’s continuous improvement. That doesn’t necessarily mean solving their technical problems for them3.

What is wrong with asking questions in a native language if on a local channel or face to face with local people? Nothing. There is absolutely nothing wrong with that. It would be silly to speak another language there. But if you really want to improve, you can tap into a greater source of information. It is your choice. Pseudo-communities will only take you so far. Because they are only generating more newbies, and not supporting newbies become experienced users. Do they produce anything but empty talk?

Why should a local community produce anything? What should the product be? I will probably write another post about this soon. But feel free to post your ideas and critics in the comments.


1: Obviously, it only makes sense if your native language is not English.

2: I would very much like to be proven wrong on this one. If you know any, please write a comment and don’t forget to include a website and date of the last meeting.

3: Also note that there is a difference between helping someone solve a problem and solving the problem. Spoonfeeding does more harm than good.

Bookmark and Share

Free Software & Linux Days 2010

Monday, March 29th, 2010

Free Software & Open Source Days of İstanbul Bilgi University and Linux & Free Software Festival of Linux Users Association are united under the name Free Software & Linux Days this year. If you have attended before, you will probably make no other plans for April 2-3.

If you have never been to this event, registration is free and can be done at the front desk. If you are remotely interested in free software or hackerdom you will want to be there. …and, of course, you are welcome.

I will be giving a Django presentation on Friday. Please come and say hello if you happen to be attending.

UPDATE: You can find the slides from presentation here. Slideshare’s importer failed to import the file I’ve uploaded properly. So please download and view the slides with Acrobat Reader.

Bookmark and Share

What’s New in django-formfieldset 1.1

Saturday, March 20th, 2010

I have just released 1.1 version of django-formfieldset. I has been almost a year since version 1.0. Here is a summary of changes for this version:

New Example Project

There is a new and improved example project. It is designed to be some sort of documentation at the same time. When you run the example project and visit different pages you will see, for each examle, Python code, template code, text of rendered result and finally the result embedded.

If you have Pygments installed all the code will be nicely highlighted.

Fieldset & FieldsetMixin Improvements

Fieldset definitions are validated now. An exception will be raised if all of your fields are not included exactly once.

Template strings that are used by as_table, as_p and as_ul methods are now class attributes. You can simply override them instead of writing your own as_* method.

FieldsetMixin provides a fieldset_dict attribute. This dictionary has slugified fieldset names as keys and Fieldset instances as values. Your fieldset declarations can still be accessed from fielsets attribute.

Rendering Improvements

There are two rendering related improvements: individual fieldset rendering and renderform template filter.

Fieldset objects have as_table, as_p, as_ul methods just like forms. Errors from hidden fields are handled correctly, but you still need to call non_field_errors() to get the top level errors. Also it is template author’s responsibility to make sure all the fieldsets are rendered.

If as_* methods are not enough for you, with renderform filter you can render your forms or Fieldsets through a custom template. It works like this:

{{ form.fieldset_dict.mytitlerenderform:"myapp/mytitle_fieldset.html" }}

If you call it without an argument formfieldset/form.html template will be used.

Bookmark and Share

Top 5 Untrends According To Me

Tuesday, February 9th, 2010

My dear friend Ochronus posted an article titled Top 5 trends and technologies in software development that got me thinking. My thoughts below. Go check Ochronus’s blog if you haven’t, he is the lead developer at Arukereso.hu.

I agree with the suggestions from the original article. Yet, I would like to change the order a little bit; DVCS and then agile (with lowercase a) and then the rest. None of my points below are cool trends, in fact I can guarantee most of you will find them boring. But I think they are all important. OK, I hope you are all psyched now. Here we go:

1. Be Careful With The Buzz

Trends are cool. What could be wrong about following cutting edge stuff? We all want to be up to date, no? I think it’s good to follow the trends if you have the experience and the ability to filter the BS. I know a young developer who was constantly going back and forth between Rails/Ruby and Django/Python. I haven’t heard from him for a while, but he is probably still doing that same dance. Why? Because his considerations were solely based on buzz, not on simple requirements analysis or technical comparisons or personal experience.

2. Learn And Use An Old-Fashioned Modern Low-Level Scripting Language

To all the scripting people, like me, out there: you need to have an understanding of what’s happening under the hood. At the least to appreciate our high-level environments, at the most to become genuinely good programmers. Being a Python person myself, I think the best low-level language to be proficient for me is C. Many other high-level languages have C interfaces. So investing the time to learn C should pay off one way or the other.

3. Do Less Web Programming

Aren’t we doing a lot of web programming these days? Actually I think doing X development exclusively is bad for your programming muscles. Web programming, enterprise work or system scripting, it doesn’t matter. But web programming happens more than anything else. Maybe some of you have only been playing with it, but there are a huge number of us doing nothing but web programming. This is so sad; both in an individual level and for the community at large.

4. Learn How To Educate Yourself

What is a noob? Here is a definition and disambiguation (from newbie):

Newbs are those who are new to some task and are very beginner at it, possibly a little overconfident about it, but they are willing to learn and fix their errors to move out of that stage. n00bs, on the other hand, know little and have no will to learn any more. They expect people to do the work for them and then expect to get praised about it, and make up a unique species of their own.

Make an active effort not to be a noob. Learn how to ask smart questions, how to communicate others and seek help. Being polite is good but actually improving and being a valuable member of the community is much, much better.

5. Open Source Properly

It’s great to open source your project. But please do it properly. There are already too many unmaintained, undocumented projects out there that noone seem to care. Do you really have to add to that? As is argument doesn’t make much sense today. But if you really have to make an open source dead drop, please at least document the status of your project and your intentions clearly.

I wouldn’t be surprised if some you think they all are obvious. But if they are so obvious then why are they widely being ignored? Is it because they are under-retweeted, under-reddited and therefore not trendy.

Bookmark and Share