When it comes to software, database systems are beneficial in many ways. They offer us to keep our data organized and a fast way to access them. However as the number of components in a software project increases, it gets harder to preserve the organized structure. In situations like this, visualizing the scheme helps to understand the structure and the relations between the tables.
Recently, I learned a new feature of screen, it is referred as “multi display mode” in the manual. You can attach to a screen session that is not detached and the session is simply shared. In this mode, anything you typed are transferred simultaneously to the other display(s) as well. My mentor from my Google Summer of Code project used this feature to work collaboratively. In order to get in to multi display mode, you need to use “-x” parameter:
If there are multiple sessions, you need to provide the session name as well:
screen -x session_name
Recent weeks, I dealt with D-Bus for my Google Summer of Code project. I was trying to control system services, and systemd has a D-Bus interface. In the beginning, D-Bus seemed a little confusing for me, but I believe I understand it now. In this post I will try to explain it in simple terms and an example.
D-Bus is a interprocess communication tool. It delivers messages to applications. The most confusing thing for me was that taxonomy of D-Bus having several terms such as bus names, objects, paths, methods, signals, properties, interfaces, proxies… But when you learn their meanings, the bigger picture gets more clear.
- Bus names are applications. They often have well known names in a format similar to namespaces in Java (e.g “com.onurguzel.MyIntergalacticApplication”).
- Objects are synonymous to the objects in programming languages, and paths are the object instances.
- Methods are functions that is run on the object, and signals are the broadcasts from the object. Properties are the constants or variables in the object.
- Interfaces are the types of the object. Thus, some object may support several interfaces. Their format is the same as bus names, but they should not be mixed with each other.
- Proxies are higher level objects. When a method is invoked on the proxy, it is converted to D-Bus method call message, sent, and reply message is returned. They offer easier operation with D-Bus then manually creating messages, sending them and waiting for a reply.
Since all major Linux distributions use NetworkManager for network connections, I preferred to create this tutorial with it.
import dbus bus = dbus.SystemBus() # Warning: Bus names and interfaces are different terms. # Just because they contain same format or even same data # does not mean they are the same thing. # I used these variables to denote the diffrance where bus names and # interfaces are used. NM_BUSNAME = 'org.freedesktop.NetworkManager' NM_IFACE = 'org.freedesktop.NetworkManager' # Create Python object from /org/freedesktop/NetworkManager instance # in org.freedesktop.NetworkManager application. nm = bus.get_object(NM_BUSNAME, '/org/freedesktop/NetworkManager') # Get list of active connections from the properties # "Get" method is in "org.freedesktop.DBus.Properties" interface # It takes the interface name which has the property and name of # the property as arguments. connections = nm.Get(NM_BUSNAME, 'ActiveConnections', dbus_interface=dbus.PROPERTIES_IFACE) # While invoking a method on the object, dbus_interface keyword # argument is provided to specify which interface has the method. # Now, lets disconnect. This time we are using the NetworkManager # interface: "org.freedesktop.NetworkManager" for path in connections: nm.DeactivateConnection(path, dbus_interface=NM_IFACE)
If you have questions about this tutorial, you can ask in the comments section below. For more information about D-Bus, my references:
- Introduction: http://www.freedesktop.org/wiki/IntroductionToDBus/
- Tutorial: http://dbus.freedesktop.org/doc/dbus-tutorial.html
- Python Tutorial: http://dbus.freedesktop.org/doc/dbus-python/doc/tutorial.html
It has been over a month since summer coding started. Unfortunately, although I am not a procrastinator, I could not perform my best on the project. Besides following news about #OccupyGezi, I have read the Pyramid documentation in the community bonding period. Coding time has also past reading documentations. I spent my time reading and understanding SQLAlchemy and designing the modules for the project in my head.
I have managed to get my focus on my work, two weeks ago. Now, I have several weeks to catch up. The mistakes I’ve made so far:
- I did not ask my mentor for advices.
- I got distracted a lot. It was very hard to handle both summer school and summer coding. Because, school has its own assignments, too.
- Even though I make my commits atomic, instead of pushing them regularly, I kept them local until I finished working on the feature.
- I did not write any blog posts about my status or what I have done.
I am not proud of this failure or mentioning it here. However, I have learned from my mistakes, and I will not repeat them. You will see more frequent updates on my project status here. Keep following!