Tuesday, July 10, 2012

Brother (stupid) printer on GNU/Linux

For some reason, brother printers (at least mine) do not take into account the settings specified for the printer in the regular way (Gnome settings in my case).

But mysteriously, there is a command which can be used to change them properly (brprintconf_mfc235c). In my case, I was having problems with top margin, and top of pages was not printed. Apparently it was because of page type, so I could fix it by:

sudo brprintconf_mfc235c -pt A4

Friday, April 27, 2012

How to make Gnome 3 suck less


While there are some cool things in Gnome 3, I think mostly everyone will agree that there are many things which sucks. To me, it looks like a bad copy of the Mac desktop, and it's specially annoying that they also brought the "let Steve Jobs decide it for you" philosophy to GNU. I don't really know who is leading the project, but look like they should send a resume to Apple.

Anyway, the reason for this post is that I realized that I'm not alone. And I realized in a strange way... Basically, it looks to be a consensus on which are the parts of Gnome 3 which suck more, and I arrived to this conclusion after seeing that there is a Fedora package to remove almost every non-sense feature Gnome brings.

These include (among others):

  • Accessibility icon always on the bar
  • Alt-tab bothering system of grouping windows
  • Power off option not hidden by secret methods


Honestly, I'm reconsidering what I said, and I think Gnome leaders already sent the resume to Apple, and they are paid to fuck up the GNU desktop. Really, hiding the power-off button... Can be anyone so stupid?

I'm not a genius, so I don't usually share my opinions in Linus Torvalds style, but I think it's totally worth in this case.

So, if you're using Gnome 3, you should probably check this link out:

http://fedoraproject.org/wiki/Features/GnomeShellConfigurability

Monday, June 27, 2011

Create user and database in Postgres

While I love Postgres, I get some problems every time I want to do the simple operation of creating a database with an associated user if it's been a while since the last time I did it.

There are several posts on the Internet about Postgres authentication, but I couldn't find any explaining exactly what I wanted to know, so here is mine.

This has been tested on Debian 6 and PostgreSQL 8.4.

1. Install the PostgreSQL server (obvious)
2. Create the user:

$ sudo -u postgres createuser -D -A -P <my-user>

3. Create the database

$ sudo -u postgres createdb -O <my-user> <my-database>

4. Edit /etc/postgresql/8.4/main/pg_hba.conf

# Put your actual configuration here
local all all password
host all all 127.0.0.1/32 password

NOTE: Make sure that your settings are placed after the comment saying where your configurations go. If you place them at the end, the default ones will be used, and you'll see this error when logging in:

psql: FATAL: Ident authentication failed for user "<my-user>"


Actually, you'll probably want to customize the settings you want to use. My settings allow logging in from localhost using unencrypted password, but may be you want to access from another host, only grant access to some users or some databases, or use another authentication methods, so I would recommend you reading the pg_hda.conf reference.

Finally, you'll be able to access by:

$ psql -U <my-user> -W

Saturday, June 25, 2011

Unified Python

After all these days at EuroPython, there is a thought that keep me thinking. It is about how Python have different ways to represent what it could be considered the same thing.

On today's talk, Alex Martelli pointed out that "def" and "lambda" are actually the same concept. This was part of a more complete idea about that both of them have the wrong name ("function" should be the right), and that lambda actually should disappear, but that's another question.

Also, yesterday, Raymond Hettinger reminded that class are actually dictionaries, something that most Pythonistas know, but which also made me thought.

Then, there is something that I never saw very clearly, and it is the subtle difference between an instance and a dictionary, and how trivial it can be in some case, the difference between person['name'] and person.name.

So, I wanted to do an experiment on how it could look Python, if it would try to merge all this entities in ones single format, and even some other things like avoiding assignments that doesn't follow the assignment pattern (I mean class or function definition here, where instead of my_func = [...] it's used def my_func[...]).

Next, there is how the most stupid example I could invent looks like, but first some definitions to make it easier to understand the idea.

map: could be also "class", "dict", "obj", "hash",... and it's the structure for dictionaries, classes and instances.
seq: a list or tuple, any linear sequence of values.
func: a function or callable, that in Python is defined by "def" or "lambda".


foods = seq:
"meat"
"milk"
"bread"

sounds = map:
"bark" = "woof woof"
"mew" = "meow meow"

animal = map:
"step_size" = None
"sound" = None

"move" = func(self, num_steps):
print("I've moved {} units".format(num_steps * self.step_size))

"talk" = func(self):
print(sounds.{self.sound})

"eat" = func(self, food):
print("I'm eating {}".format(food))

cat = map(animal):
"step_size" = 80
"sound" = "mew"

"eat" = func(self, food):
print("I only eat {} if I want to".format(food))


azrael = map(cat):
"owner_name" = "Gargamel"

azrael.move(5)
for food in foods:
azrael.eat(food)


Of course, there are too many things that should be considered before being able to implement this syntax, but can give an idea on how it could look a more unified approach of Python syntax.

See how the syntax for "sounds", which would be a dictionary, "cat", which would be a class, and "azrael", which would be a instance, is exactly the same.

Being used to Python syntax, it's difficult to say if this syntax could be readable, so far I just find it weird. But what looks clear, is that this syntax would make the language simpler, from the implementation point of view, and probably from the programmer point of view, who would probably need to forget some OP concepts first.

Whatever is the conclusion the reader can get from this example, I think it's quite interesting seeing how a class can look exactly the same way as a dictionary, and how an instance can look exactly as a subclass of the base class.

Saturday, June 11, 2011

Building RPMs for Python3.1

While it's been a long time since the first stable version Python 3 was released, it's not yet available on several operating systems. Looking for a repository with Python 3 rpms, I found IUS Community, but I had some problems with it, and I thought on building my own rpms.

The process for building an rpm from a source tarball is pretty easy (if you know the steps). The only problem in this case, is that the .spec file delivered with Python is not updated, so the process fails.

I did required changes to the .spec file, and I uploaded it to: http://files.vaig.be/python-3.1.spec (NOTE, that is necessary to edit the exact version of Python you're building in line 37. Version in uploaded file is 3.1.3, but it could be changes to 3.1.3, 3.1.4rc1,...).

Next, you can find the steps for creating a RPM package for Python 3.1 on a CentOS 5 (using my custom .spec file):


# Install required software
yum install rpm-build gcc expat-devel db4-devel gdbm-devel sqlite-devel ncurses-devel readline-devel zlib-devel openssl-devel

# Download Python source
cd /usr/src/redhat/SOURCES/
wget http://www.python.org/ftp/python/3.1.3/Python-3.1.3.tar.bz2

# Download .spec (rpm specifications file)
cd /usr/src/redhat/SPECS/
wget http://files.vaig.be/python-3.1.spec

# Generate RPMs (and SRPMs)
rpmbuild -ba /usr/src/redhat/SPECS/python-3.1.spec


Compiling Python and creating the RPM will take a while, but after this process, you'll have the RPMs at:


/usr/src/redhat/SRPMS/python3.1-3.1.3-1pydotorg.src.rpm
/usr/src/redhat/RPMS//python3.1-3.1.3-1pydotorg.i386.rpm
/usr/src/redhat/RPMS//python3.1-devel-3.1.3-1pydotorg.i386.rpm
/usr/src/redhat/RPMS//python3.1-tools-3.1.3-1pydotorg.i386.rpm

Sunday, December 26, 2010

Joel test for software companies

Today I discovered Joel test, a test to evaluate software companies. While the article is pretty out-of-date, and there are some points that are exclusively for companies working on compiled programming languages, the article is still very interesting.

I think every software company should took the test. Also I think it can be useful for programmers, to evaluate if a company is a good place to work.

The original article is at:
http://www.joelonsoftware.com/articles/fog0000000043.html

Let me provide a summary of original questions here:
  • Do you use source control?
  • Can you make a build in one step?
  • Do you make daily builds?
  • Do you have a bug database?
  • Do you fix bugs before writing new code?
  • Do you have an up-to-date schedule?
  • Do you have a spec?
  • Do programmers have a quiet working conditions?
  • Do you use the best tools money can buy?
  • Do you have testers?
  • Do new candidates write code during their interview?
  • Do you do hallway usability testing?
My personal update to the questions would be:
  • Do you use a distributed source control system?
  • Do you use a bug database where users can report bugs directly?
  • Do you have a testing protocol, and specific resources for testing?
  • Do you fix bugs before implementing new features?
  • Do you have automated build or deployment procedures?
  • Do you have a roadmap, and you don't make important changes to the short term priorities?
  • Does your team work in good conditions (quiet environment, flexible schedule, freedom to choose development software, fair paycheck...)
I think those questions can give you an idea on how efficient your company is, and indirectly, about the quality of your software.

Saturday, December 25, 2010

Branching with Mercurial

This is a simple guide on how to do simple branching operations in Mercurial.

First of all, let's comment the two different options for branching on Mercurial, and in most distributes source control systems.

First option is to create a clone of the original repository to create a branch. This option can be simpler for the user, which has different directories for every branch, and there are not special operations to switch from one branch to another. Another advantage is that branches can be safely switched when some changes are not yet commited, as every branch is in a different directory.

The second option would be to use Mercurial branching commands, and to keep all branches in the same repository. The main advantage of doing this, is that branches can be distributed when using push and pull operations. This is very important, if different programmers need to work with different branches, or if you want to replicate all branches when synchronizing your code with for example Google code or Bitbucket.

This second options is the one I'll cover in this simple guide.

Imagine we have a started repository, with some code, and we never used branching before.

If we perform:


# hg branches
default 69:3f5490390a0b


we can see that we already have a branch named default, that is the one that has all our changesets and code.

Now we want to start working on a new version of our application, but we want to be able to do bugfixing to the application we already deployed. We can do it, creating a new branch on our repository.

Look at this example that creates a new branch named newversion, and we create a new file named newfile on it.


# hg branch newversion
# touch newfile
# hg add newfile
# hg commit -m "commit on the new branch newversion"


After this, if we check for the branches again, we'll have this:


# hg branches
newversion 70:720062b481d7
default 69:3f5490390a0b (inactive)


After working on the new branch, we find a bug on the deployed version, and we want to fix it on the version that is deployed. So we have to switch to the default branch to see the content of this branch in our repository directory. We can get it by simply typing:


# hg update default
# > bugfixedfile
# hg add bugfixedfile
# hg commit -m "bug fixed in default branch"


NOTE, that we shouldn't have files that are not under the control version system, and that are specific to a branch in the code, as Mercurial will keep those files on the new branch after switching. We can use the option -C if the files are temporary and we want to clear them.

To know the current branch, we can use branch command with no parameters:


# hg branch
default


After fixing the bug in the default branch, we'll probably want to fix it in the new version too, so we'll proceed by:


# hg update newversion
# hg merge default
# hg commit -m "merged from branch default"


After the new version is ready to be deployed, we'll probably want to merge it back to default, so default will go on being the deployed version. It's recommended to have all changes to the default branch merged to the new version branch, before merging it back to default.


# hg update newversion
# hg merge default
# hg commit -m "merged from branch default"

# hg update default
# hg merge newversion
# hg commit -m "merged branch newversion into default"


Finally, the last thing we would want to do is to close the branch where we developed the new version, as further changes to this version will be made to the default branch. It's as simple as:


# hg update newversion
# hg commit --close-branch -m "closing branch newversion after being merged to default"