Lucas Almeida Rocha: Introducing The Board

GUADEC 2010 is about to begin and, unfortunately, I will not attend it this year. But I think it’s a good time to introduce a small cool project I’ve been gradually working on in my (rare) spare time. I’d like to present you The Board.

What is The Board? It’s a space for quickly placing daily records: photos, video, audio, text, and more. Think of it as a combination of a note-taking space, a photo or video booth, photo album, sketching board, a digital diary, and (in the future) a nice way to quickly share stuff with your friends. Click on the image above to watch a video showing how the app works now.

The focus is to provide a quick, simple and visually engaging way of keeping small records of your day. I envision The Board as a sort of especial workspace in GNOME. Something that’s “always there” and is tightly integrated with the desktop. For now, it’s simply an app that always runs in full screen – so that I can demonstrate the idea more accurately.

Add to The Board. The Board can be used a quick note taking app. Someone is telling you a phone number you want to take note of? Switch to The Board, press “s” (or use the toolbox) and quickly write down the phone number. You have a favourite photo for the day? Switch to The Board, press “p” and select the photo file (similar thing for video and audio). Want to write down some ideas before you forget them? Switch to The Board, press “t”, and you have a nice lined note paper to write in. Want to record a quick video with a happy family moment? Switch to The Board, press “v”, and you can start recording the video. You got the idea. For now, I have only implemented simple text elements (lined paper and sticky note) and photo. There’s more coming (see “Next steps” below).

One page at a time. You don’t need to remove old things or “manage” the things on The Board. Once you filled the whole screen space, just create another page! Your previous content will be saved and can be easily accessed through the Pages toolbox. You don’t even need to worry about saving your content. The Board saves the latest content of your page every time your change it by editing, adding or removing things, etc.

What is it made of? The Board is built on top of bleeding edge GNOME platform. It’s written in Javascript using the GObject Introspection-based Gjs. The UI is fully written with Clutter and Mx (with some small bits of GTK+ and Clutter-GTK+). It’s a nice example of how you can do cool apps using the GNOME platform nowadays.

What’s the current state? The initial core code and framework is in place. But there are obviously tons of things to be done. The app is not even installable yet! I’m still sketching the API to implement plugins. Video and audio elements are not implemented yet. The graphic design is poor (as I did it myself using some random graphics from internet) and there are lots of open interaction design questions to be sorted out. In order to run the app for development purposes, you’ll need a full GTK+ 3 stack, and latest (as in git clone master) clutter, clutter-gtk, mx, gobject-introspection, and gjs. The official code is in gitorious now.

How can I help? If you want to hack on The Board, grab the code, build it and run it. Play with the app and bring ideas, fix bugs, implement new features, etc. Business as usual. If you’re an interaction designer, you can help by solving some of the hard questions still needing answers in terms of usability and user experience :-) On the graphic design front, I’d really like to have better graphics for all UI elements. I have to find a nice free (as in freedom) font to use in the UI. I’m temporarily using this funny freeware font. Users can help by giving constructive feedback on how we can make The Board more interesting, useful, and exciting. In any case, contact me and we can discuss how and what to do.

So, what are the next steps? As I said before, there are tons of things to be done. Here’s what I have in mind in terms of short-term and long-term roadmap.

Come up with a simple Plugin API. By plugins I mean either the implementation of new types of things to be added to The Board’s pages or new types of background – which can contain animations and react to user events by the way. For example, a background could be a wooden table with a light switch that can be turned on and off. Or the background can change colour depending on the current time of the day.

Integration with other apps. Basically, users should be able to add new things to The Board through existing apps. For example, An Add to the Board option in Nautilus when right-clicking image, video, audio, or text files. Similar thing with apps like EOG or F-Spot – an Add image to The Board option. Integration with web browsers would be nice too: saw an interesting image on a webpage? Just add it to The Board. Or maybe add your text selection as a sticky note in The Board. Still on the app integration front, I’m doing some work to integrate a Cheese dialog into The Board so that you can add photos and videos from webcam without having to switch apps.

Online experience. This is one area that I’m still unsure how to handle. My initial idea is that you can share anything in The Board pages. From a user perspective, you would just add something to The Board and click “Share”. On the server side, I’m thinking of having a WordPress instance with a plugin to present The Board’s custom types just like you see them in your desktop. i.e. sticky notes in The Board should look exactly the same in your “Board webpage”. The advantage of implement this as a WordPress plugin is that it would be installable in a large number of personal servers from day one. Tumblr is definitely the main inspiration in terms of online experience here as it offers a rich media blogging approach.

Anyway, you probably got the idea after reading this (maybe too) long blog post. If you got excited about The Board and want to help with code, graphics, design ideas, or just simple feedback, post a comment here or contact me directly. I’ll be hacking on The Board in my spare time as usual. But things can definitely move much faster if it gets more people involved. If you’re into writing simple and beautiful software using GNOME’s latest technologies, this should be a fun project to contribute to!

Carlos José Pereira: "Esse pessoal de Piracicaba, não é mole não!!"

Costumo ouvir (e fazer...) muitas críticas à nossa Universidade, em especial por conta da burocracia absurda que assola nosso trabalho docente e de pesquisa, no dia-a-dia.

Mas dessa vez, devemos aplaudir de pé!! O motivo é a nomeação, feita pelo CONSU/UESC, do novo prédio da Pós-Graduação como PAVILHÃO PROF. MAX DE MENEZES.

Não tive, infelizmente, muito contato com o Max no dia a dia. Mas nesse pouco contato já dava pra sentir aquela simpatia infinita, acompanhada daquele sorriso maroto piracicabano... O cara era, simplesmente, muito gente boa!!

Vai ser bom entrar no Pavilhão Prof. Max de Menezes. Vai ser como estar perto do coração dele mais uma vez.

Tchau Max! A gente se esbarra por aí um dia desses!

Abraços!

Carlão

pedro kroger: Configuring Emacs as a Python IDE

Emacs is a huge beast. It can read email, play tetris, act as a file manager, display google maps, and even edit videos. It has support for many, many programming languages and has many features related to programming. Unfortunately, emacs doesn’t have a full programming environment for python out-of-the-box.

In this post I’ll show how to configure emacs to write Python programs. We want to have not only basics things like syntax highlighting, but also code completion, easy access to Python’s documentation, ability to check for common mistakes, run unit tests, debugging, and a good interactive programming environment.

This setup is based on ipython and python-mode, but it’s also possible to use rope, ropemacs, and the auto complete mode as we can see here. I didn’t have much luck with ropemacs in the past but I’ll try it again in the future.

Tools installation and configuration

First we should install the tools we need.

• python-mode. There are two python modes; python.el and python-mode.el. Although python.el comes with GNU Emacs 22, I recommend you use python-mode.el since it has support for ipython. (There’s some talk about merging the two modes, but I don’t know it’s current status). Download and install python-mode.el and put the following in your .emacs:

  (require 'python-mode)
  (add-to-list 'auto-mode-alist '("\\.py\\'" . python-mode))

• ipython. Ipython is a powerful python shell with advanced features and nice code completion. Check ipython’s website for documentation and screencasts. If you’re using debian or ubuntu, install it with:

  sudo apt-get install ipython

  To configure ipython, edit ~/.ipython/ipy_user_conf.py and add your options. I like to use ipy_greedycompleter so it will complete things like "foo".TAB.

• ipython.el. It allows you to use python-mode with ipython. Download and install ipython.el and put the following in your .emacs:

  (require 'ipython)

• lambda-mode. This is only for aesthetics. When you install lambda-mode.el it will display a lambda character (λ) when you type lambda:
  The full name “lambda” will still be there, emacs is only displaying it differently. I like lambda-mode because it makes the code look shorter, neater, and cooler. Download and install lambda-mode.el and put the following in your .emacs:

  (require 'lambda-mode)
  (add-hook 'python-mode-hook #'lambda-mode 1)

  I had to set the variable lambda-symbol to the following, but YMMV:

  (seq lambda-symbol (string (make-char 'greek-iso8859-7 107)))

  There are other ways to have pretty lambdas and pretty symbols in emacs, check the Emacs Wiki page to see which one you prefer.

• anything. We will use anything for code completion. Download and install anything.el, anything-ipython.el, and anything-show-completion.el, and add the following to your .emacs:

  (require 'anything)
  (require 'anything-ipython)
  
  (when (require 'anything-show-completion nil t)
     (use-anything-show-completion 'anything-ipython-complete
                                   '(length initial-pattern)))

• Change comint keys. Comint is a minor-mode to deal with interpreter commands in an emacs buffer. It’s used by many modes, including ipython. Comint uses M-p and M-n to cycle backwards and forward through input history. I prefer to use the up and down arrow keys:

  (require 'comint)
  (define-key comint-mode-map (kbd "M-") 'comint-next-input)
  (define-key comint-mode-map (kbd "M-") 'comint-previous-input)
  (define-key comint-mode-map [down] 'comint-next-matching-input-from-input)
  (define-key comint-mode-map [up] 'comint-previous-matching-input-from-input)

• pylookup. We will use pylookup to search python’s documentation within emacs. First install the python documentation locally. If you use debian or ubuntu you can install it with one command:

  apt-get install python2.6-doc

  If the python documentation is not available as a package for your system, download it from the python website and unzip it somewhere in your computer. Then download pylookup and follow the instructions in the README file. Run pylookup.py to index the database by running:

  ./pylookup.py -u file:///usr/share/doc/python2.6-doc/html

  This command will generate a database file (pylookup.db). Naturally, you need to put the correct path for the python documentation. Next you need to add the following to your .emacs. Again, replace the values to match your system.

  (autoload 'pylookup-lookup "pylookup")
  (autoload 'pylookup-update "pylookup")
  (setq pylookup-program "~/.emacs.d/pylookup/pylookup.py")
  (setq pylookup-db-file "~/.emacs.d/pylookup/pylookup.db")
  (global-set-key "\C-ch" 'pylookup-lookup)

• autopair. A common feature in modern editors is to insert pairs of matching elements such as parenthesis, quotes, and braces. There are many ways to do this in emacs and installing autopair.el is probably the easiest one. You can configure it to work in all modes and exclude the modes you don’t to have it activated. For instance, I have it configured to work globally, except in the lisp-mode, where I use paredit:

(autoload 'autopair-global-mode "autopair" nil t)
(autopair-global-mode)
(add-hook 'lisp-mode-hook
          #'(lambda () (setq autopair-dont-activate t)))

I also have the following to in my .emacs to make autopair work with python single and triple quotes:

(add-hook 'python-mode-hook
          #'(lambda ()
              (push '(?' . ?')
                    (getf autopair-extra-pairs :code))
              (setq autopair-handle-action-fns
                    (list #'autopair-default-handle-action
                          #'autopair-python-triple-quote-action))))

apt-get install pylint pep8

(require 'python-pep8)
(require 'python-pylint)

(add-hook 'before-save-hook 'delete-trailing-whitespace)

ipdb package. The ipdb package makes it easy to set breakpoints in the ipdb debugger. It’s easy to install it using easy_install (duh ):

easy_install ipdb

sudo easy_install reimport

(require 'yasnippet-bundle)
(yas/initialize)
(yas/load-directory "~/.emacs.d/my-snippets/")

You can also install flymake to check the syntax on the fly. I find it distracting, so I don’t use it.

All right, these are the tools we need! Now we can go on and use these features.

Using emacs-mode

So now we’re ready to go. Open a python file, say test.py, type C-c ! (py-shell) to start the python interpreter. Go back to test.py (with C-x o) and type C-c C-c (py-execute-buffer) to send the whole buffer to the interpreter. In the following picture we can see how it works; it’s neat to be able to write code in one file and test it in the interpreter without the whole edit-compile-run-test cycle:

Code completion

Code completion is very useful and I find a must to be able to complete methods for both built-in and user-defined classes. For instance, if you type “os.path.” and M-tab emacs will show all methods available in os.path:

This completion method uses anything and you can use C-n and C-p to navigate through the completion items (when you’re done type return). This works for used-defined methods and functions too:

Access to documentation

Python has excellent documentation and it’s a huge bust in productivity to be able to access the documentation without leaving the editor. By using pylookup we can type C-c h to search any term in the python documentation. For instance, if we type “os.path.basename” and then C-c h to invoke the documentation, pylookup will open the documentation page for os.path.basename using the default browser configured in emacs (usually firefox):

However, many people prefer to use w3m inside emacs to browse technical documentation. With w3m we can read the documentation without leaving emacs, making it easy to copy code snippets and not needing to switch to an external program (to much switching can kill focus). Here’s the same documentation in the above picture but using w3m this time:

If you search for something with more than one possible answer, pylookup will ask you to choose among some possibilities, for instance, if I search for print I’ll get many options to choose from:

Code quality

The pep8 script checks if your code follow the PEP8 style guide. You can run it inside emacs by typing M-x pep8. The key M-x ` will jump to the place in the source code where the next error occurs:

You can run pylint inside emacs with M-x pylint, it behaves in a similar way to pep8:

Unit tests

It’s possible to run unit tests inside emacs if we use the compilation mode.  Type M-x compile and replace what will appear (most likely “make -k”) with your favorite python program to run unit tests. As with pep8 and pylint (they both use the compilation mode), you can type M-x ` to navigate to the next error. In the following screenshot we can see that test_square_of_100_is_1000 is not correct:

Debugging

There are many ways to debug python code. I like to use ipdb, ipython’s debugger, because it has advanced features like code completion and syntax highlighting. With the -pdb flag Ipython will go directly to the debugger when an exception is raised, instead of just printing a stack trace. (you may want to edit ~/.ipython/ipythonrc to make the change permanent).

To set breakpoints in the regular python debugger, you need to add the following lines to your code:

import pdb; pdb.set_trace()

With the ipdb package we can set breakpoints in a similar way if using ipdb:

import ipdb; ipdb.set_trace()

I like to make emacs highlight the lines that set breakpoints, so I can easily visualize where the breakpoints are and remember to remove them from the code after I’m done debugging. I use the following code to accomplish that:

(defun annotate-pdb ()
  (interactive)
  (highlight-lines-matching-regexp "import pdb")
  (highlight-lines-matching-regexp "pdb.set_trace()"))

(add-hook 'python-mode-hook 'annotate-pdb)

Notice in the following screenshot how the line that sets the breakpoint is highlighted and the program execution stopped at the breakpoint. I used the command n (next) to advance to the next statement:

I have a function to add breakpoints mapped to C-c C-t so I can set breakpoints easily:

(defun python-add-breakpoint ()
  (interactive)
  (py-newline-and-indent)
  (insert "import ipdb; ipdb.set_trace()")
  (highlight-lines-matching-regexp "^[ 	]*import ipdb; ipdb.set_trace()"))

(define-key py-mode-map (kbd "C-c C-t") 'python-add-breakpoint)

Templates

For textmate-like templates I use yasnippet (be sure to watch its demo). With it you can define templates easily and quickly to fill things for you, like a new-style class with documentation and an __init__ method. Python doesn’t have much boilerplate, but using yasnippet can help you to write code even faster.

Finding your way in the source code

Emacs allows us to navigate through source code by using tags. When you see a function call you can jump to its definition with M-. (find-tag) and jump back with  M-* (pop-tag-mark). Another useful command is tags-query-replace, to rename functions, methods, etc. To use it we need to generate a TAGS file. Emacs comes with the etags command but I recommend exuberant tags:

sudo apt-get install exuberant-ctags

Usually I put the following code in a Makefile to generate a TAGS file for a project:

ctags-exuberant -e -R --languages=python --exclude="__init__.py"

Dealing with multiple files

As we have seen, we can program in an interactive style in python-mode by sending the buffer to the python interpreter with C-c C-c. This works well for single file scripts and libraries, but no so well for more complex modules with sub-modules. For instance, if you open file4.py in the mainmodule bellow and execute it with C-c C-c it’ll fail if it depends on other submodules.

mainmodule
|--- __init__.py
|--- submodule1
     |--- __init__.py
     |--- file1.py
     |--- file2.py
|--- submodule2
     |--- __init__.py
     |--- file3.py
     |--- file4.py

We can define a master file using the py-master-file variable; python-mode will execute the file set in the variable instead of the current buffer’s file. This variable can be set as a file variable, but I prefer not to pollute every single freaking .py file in a module with a file variable, so I use a directory variable instead. Another advantage of using directory variables in this case is that each member of a team can set the py-master-file to reflect their file system layout. Create a file called .dir-locals.el in mainmodule‘s root with the following content:

((python-mode . ((py-master-file . "/path/to/interactivetest.py")
                 (tags-file-name . "/path/to/TAGS"))))

(Note that I also define the tags’ filename, so emacs’ll automatically load it when I read a python file located in this directory.)

To make this work I use a master file called interactivetest.py in the module’s root to re-import the module with the reimport package. This file is not really part of the module and I don’t even check it under version control. Now, every time we hit C-c C-c, regardless of what file we are changing, python-mode will execute interactivetest.py again, and update the whole module. For instance, this is what I have in the interactivetest.py for my aristoxenus library:

import reimport
import aristoxenus
reimport.reimport(aristoxenus)

But I may add a few things in the interactivetest.py file to make testing things interactively easier and to be able to save it between coding sessions:

from aristoxenus.parse import humdrum
foo = humdrum.parse_string("**kern\n4C")

Of course this is not a substitute for unit tests, but it’s nice to have foo available in the REPL so I can inspect it and quickly see what’s going on.

Conclusion

As you can see, we can have a nice programming environment for python in emacs. It may look like a lot of work, but in reality we only need to download and configure already existing packages. However, it would be nice to have a full-fledged development environment for python like slime.

I didn’t mention many things like the emacs code browser, the git interface, and the window session manager. They are not particularly specific to python, but they contribute to turn emacs into a powerful tool for development. Maybe I’ll mention then in another post.

I intend to make a screencast in the future showing these features, so stay tuned. Meanwhile, what do you use to develop python code?

Alexandro Silva: Black Hat – Palestrante apresentará roteadores xDSL vulneráveis a ataque de DNS rebinding

O pesquisador de segurança da Informação Craig Heffner da Seismic apresentará a palestra “How to Hack Millions of Routers.” na próxima edição da Black Hat que ocorrerá de 24 a 29 de julho em Las Vegas.

Nesta palestra será apresentado um ataque capaz de invadir roteadores ADSL de vários fabricantes como Dell, Linksys, Verizon Fios entre outros. Ele está desenvolvendo um software capaz de invadir estes roteadores usando a variante de uma antiga técnica conhecida como “DNS rebinding”.

A vulnerabilidade que permite este ataque já foi “corrigida” a anos, porém Heffner afirma que a correção não foi bem aplicada permitindo que usuários conectados tenham suas sessões captudas ( hijacking ) e suas informações roubadas.

A falha é explorada através do DNS ( Domain Name System ), segundo Heffner será criado um site “isca” que ao ser acessado executará um script. Este script fará a captura da sessão permitindo que o atacante acesse a rede da vitima.

A dúvida que paira no ar é como este ataque será apresentado no evento, pois os navegadores possuem ferramentas de detecção quando um site está infectado com um possível malware. O pesquisador afirma que as correções implementadas no OpenDNS e no plugin NoScript do Firefox não bloqueiam o ataque.

Veja a lista dos equipamentos onde a invasão foi bem sucedida:

Mas nada é fácil como parece. Para o ataque ser bem sucedido o roteador da vitima deverá possuir alguma vulnerabilidade explorável ou simplesmente estar configurado com a senha padrão do usuário admin. O que não será muito difícil de encontrar já que são pouquissimos usuários que se preocupam em alterar a senha padrão do seu roteador ou mantem o firmware do equipamento atualizado.

Então segue a dica de ouro:

“Mantenham o firmware dos seus routers atualizados e alterem a senha padrão do usuário admin”

E como o próprio Heffner diz:

“Eu não sou o primeiro a falar na Black Hat sobre DNS rebinding, nem serei o último…”

Fonte:

“Millions” Of Home Routers Vulnerable To Web Hack

Referências:

DNS rebinding
Protecting Browsers from DNS Rebinding Attacks
[Video] DNS Rebinding with Robert RSnake Hansen

Rafael Gomes: Instalando o eAccelerator no Debian Lenny

eAccelerator é uma ferramenta sob licença livre, criada para otimizar/acelerar o uso do PHP no servidor. Ele é responsável por aumentar a performance de scripts PHP através de cache desses scripts em estados de compilados, assim esse overhead de compilação é quase completamente eliminado.

Eu acredito que a aplicação tem que ter suporte a esse tipo de “aceleração”, pois na aplicação que precisei configurar (Moodle) tinha uma opção que explicitamente informa que usará o eAccelerator, ao invés da opção nenhum que está setada por padrão.

A instalação é simples, efetue os passos abaixo e seja feliz:

Será necessário o pacote php5-dev, que contém os códigos fontes do PHP5, que será usado para compilação do acelerador PHP. Digite os seguinte comando:

# aptitude install php5-dev
# cd /usr/local/src
# wget http://bart.eaccelerator.net/source/0.9.6.1/eaccelerator-0.9.6.1.tar.bz2
# tar xvjf eaccelerator-0.9.6.1.tar.bz2

Precisamos preparar o ambiente, com os comandos abaixo iremos exportar a variável PHP_PREFIX para o ambiente, que será utilizado em outros passos:

# export PHP_PREFIX=”/usr”
# $PHP_PREFIX/bin/phpize

É necessário criar o diretório, com a devida permissão, e modificar um parâmetro do kernel para o funcionamento do Eaccelerator:

# mkdir /var/tmp/eaccelerator
# chown www-data:www-data /var/tmp/eaccelerator
# echo “268435456″ > /proc/sys/kernel/shmmax

Com os comandos abaixo iremos preparar e iniciar o processo de compilação do código fonte do Eaccelerator:

# cd eaccelerator-0.9.6.1
# ./configure –enable-eaccelerator=shared –with-php-config=$PHP_PREFIX/bin/php-config
# make
# make install

Obs : Lembre-se que é necessário o compilador gcc e binário make para execução dos passos acima.
No Debian é possível instalar com o comando abaixo;
# aptitude install build-essential

Adicione no o arquivo /etc/php5/apache/php.ini o seguinte conteúdo:

; Eaccelerator

extension=”eaccelerator.so”
eaccelerator.shm_size=”256″
eaccelerator.cache_dir=”/var/tmp/eaccelerator”
eaccelerator.enable=”1″
eaccelerator.optimizer=”1″
eaccelerator.check_mtime=”1″
eaccelerator.debug=”0″
eaccelerator.filter=”"
eaccelerator.shm_max=”0″
eaccelerator.shm_ttl=”360000″
eaccelerator.shm_prune_period=”0″
eaccelerator.shm_only=”0″
eaccelerator.compress=”1″
eaccelerator.compress_level=”9”

Após essa configuração, reinicie o apache com comando abaixo:

# /etc/init.d/apache2 restart
Acesse o arquivo /etc/sysctl.conf e adicione as seguintes linhas:

# Eaccelerator
kernel.shmmax = 268435456

Leonardo Couto Conrado: IPFW - Criação de regras no IPFIREWALL

# mkdir -p /tools/firewall

# touch /tools/firewall/rules.fw

vi /tools/firewall/rules.fw

### Liebrar udp da rede 192.168.0.0/24  para a rede 192.168.1.0/24
add 00100 allow  udp  from 192.168.0.0/24   to 192.168.1.0/24      in
### Regra para o INPUT do trafego SSH
add 00200 allow  tcp  from any              to 192.168.1.1/32 22   in
### Regras para o INPUT do VNC da rede 192.168.1.0/24  para VNCs na rede 192.168.1.0/24
add 00300 allow  tcp  from 192.168.1.0/24   to 192.168.0.0/24 5900 in setup