Sascha Tayefeh

Blogging about Information Technology

Howto reverse scroll direction in OSX Lion

The very first thing I did after Apple OsX Lion (10.7) was to reverse the scroll direction. After googleing a while, I learned that there is supposed to be an option

System Preferences -> Select Trackpad -> “When using gestures to scroll or navigate, move content in the direction of finger movement.” to be unselected.

This reverses the reverse scroll direction Lion sets per default. However, in my case, there is no Trackpad found, because I carried out this operation with a MacMini. I switched to the “Mouse” pad and unselected “Move content in the direction of finger movement …“.

Finally, there is a third method:

defaults write ~/Library/Preferences/. GlobalPreferences com.apple.swipescrolldirection -bool false

Now, the command line above does it. I just opened my command line terminal and entered that command to reset scroll direction in OSX Lion. Then, log out and log in and you should have the same effect.

Google Plus – Report of an Early Adopter

More than a year ago, I posted my early experience with Google Buzz. I used to be quite impressed, though, I was somewhat skeptic too. It all felt to me like Google was desperately trying to catch up with e.g. Twitter, hastily creating something alike. They at least tried to add some  value by enabling embedded media, but … the  value added was apparently not enough to make the vast majority of users deflect their social media provider they got used to. I presume, for example Twitter had – and still has – some advantages:

  • First and foremost, the Google Buzz apps and clients seem to me to be less sophisticated than, for example, the ones of Twitter. Even on my Google Nexus, Google’s own buzz app to me is less fun than other social media apps. When lacking a good signal, Google Buzz fails and then just drops the message! In constrast, there is an number of e.g. Twitter apps which satisfy my needs in all situations.
  • Second, while personal twitter accounts interact just fine with most Twitter clients, it seem to me that third party Google Buzz clients fail to load and display private messages (imperfect API?)
  • Third, imo the integration into GoogleMail stands in stark contrast to the principle of “The Separation of Concerns“. And yes, I often do prefer a fat client over a web application. Is it the Google Buzz API that makes it hard – or even impossible – for third party developers to build such a client? If so, I am sure, Google could do much better.

There is an interesting article that tries to analyze what Google Buzz has become.

Now, one year later, Google gives social media another try: Google+. In contrast to the emotions I had last year when testing Google Buzz, Google+ feels completely different. Actually, I think I can feel the power, the determination, the fun, and, of course, the ingenuity  a whole bunch of excellent Google developers must have been putting into the development of Google+:

  • First and foremost, it seems to me that Google is determined to re-invent the social mashup GUI. While there have been some – afaiac poor – attempts to do this, the Google+ GUI looks different to me: It’s clean. It’s intuitive. It’s focused on privacy, and yet, on productivity. To me, this GUI is the greatest value Google+ has created. No matter what refinement may follow, I think this puts Google+ on the winning side. I believe that the developer team has considered all of the lessons learned from the mistakes and imperfections of the first generation of social media, and now they have been developing the second generation – the first Social Media 2.0.
  • Second, as already mentioned, with Google+, the developers seem to take user privacy seriously. Many users concerned with the lack of security of their current social media provider might find this another important value Google+ added. Consider me as one of them.
  • Third, I believe that Google’s Mobile Android App rocks. If they manage to release this App for the iPhone, I fancy they’ve made it.

However, I might be a little too much of an enthusiast. Some may say this is just another hype, and the vast majority might be quite happy with their social media they’ve got used to. Mashable has published an interesting article “Can Google+ Sustain Growth Beyond Early Adopters?“. And I agree with the author … partially.

What the above mentioned article does not consider, however, is the huge dissatisfaction many users might have with the privacy policy of their current social media provider. The reason, why many have not deflected, yet, might be the trivial fact, that there has been no alternative … until today. Now, there is a real alternative. Now, users do have a choice. However, the math in that article is still to be considered, and this is, where I am too much of a statistician to get blinded by my own enthusiasm … time will tell.

Howto install a stable, non-experimental Blender/Yafaray package on Windows

It took me hours to figure out how to get Blender running with windows and yafaray. There are some more or less experimental Yafaray export scripts for the latest Blender 2.5x-series. But none of them is my cup of tee.

EDIT 18.07.2011

Forget about all the instructions below. Reading Yafaray’s Facebook page, which, btw, is an excellent ressource for advice, I found a link to some pre-compiled packages for all OSes:

http://www.graphicall.org/megasoft78

Just download, unpack and start blender. No need to set any paths or pre-install python or whatsoever. You will then find YafaRay available by selecting the rendering engine from the menu bar:

Blender25 - Yafaray enabled

I’ve realized that for me it’s best to use the old version Blender 2.49a rather than the current 2.5x-series.

All in all, you need to get three components:

  1. Python 2.6.6 – http://www.python.org/download/releases/2.6.6/
  2. Blender 2.49a – http://download.blender.org/release/Blender2.49a
  3. Yafaray 0.1.1 – http://www.yafaray.org/download

It is crucial to make use of precisely tjese versions, because all need to suite to the same python version.

Also, refer to http://www.yafaray.org/community/forum/viewtopic.php?f=13&t=2423 in case you should run into any further problems.

Now here is what worked for me

 

  1. First, I installed Python 2.6.6. I set the PATH and the PYTHONPATH variable to point to the main install directory of Python
  2. I unzipped Blender 2.49a. Mind the [BLENDER_INSTALLDIR]/.blender/scripts directory
  3. I started the Yafaray 0.1.1 installed. When asked by the installer to choose the blender script directory, I located [BLENDER_INSTALLDIR]/.blender/scripts
  4. Starting Blender from the [BLENDER_INSTALLDIR], I had Blender found both, the Python and the Yafaray stuff :-)

Cheers
Sascha

GIT – Walkthrough the Integration Manager Workflow

Many people switching from Subversion to GIT wonder about the somewhat different workflow. When it comes to collaboration, Subversion users are used to a centralized workflow where we have a single dedicated central repository. In such a scenario, all developers have read and write access to that one central repository. The main issue with this is that a single user committing  buggy code has a heavy impact on all other developers (Of course, you can always revert, but it has cost us so much time and has happened so often that avoiding this is the much better choice) . Hence, it would be much better, if we could have more than a single central repository, in particular, one central repository per developer – to share every developer’s code – plus one main repository, to which write access is granted to an integration manager only. This will prevent the main repository being smashed by buggy code.

In the GIT universe, the latter scenario is referred to as “Integration-Manager Workflow” and the main repository is named “blessed” repository. We found that this workflow is extremely useful. Still, whenever a new member used to Subversion enters our team, he runs into heavy issues. Apparently, it is easier to start a workflow from scratch than to switch from another workflow.

In this article, we will walk through the Integration-Manager Workflow. As always, this is not a tutorial or even a manual. There are excellent documents on the web that explain GIT concepts in details (e.g. a free eBook “ProGit” and an exhausting tutorial by the GIT team). Here, we assume that you are familiar with GIT, branches and local and remote repositories. Also, we assume that you know how to access local and remote repositories.

In the scenario described here it is assumed that we have a local user developing on his own machine while he has access to a remote workstation hosting GIT repositories available to the rest of the team members. Such a scenario is shown in Fig. 1. Since the remote workstation is located in the cloud, we heavily recommend using ssh for communication. As show, the developer has only read access to the blessed repository, while full access is granted to him to his own repository:

GIT - Infrastructure diagram of the integration manager workflow

Fig. 1: Infrastructure diagram of the integration manager workflow

This walkthrough starts at the point, where you have cloned your own remote repository (or created a remote repository from your own). Fig. 2 shows the typical use case where the local developer fulfills two main task: 1. Get changes from the main (blessed) remote repository and 2. Send his changes to his own remote repository to make them available to other developers and, in particular, to the integration manager:

GIT - Integration Manager Use case

Fig. 2: GIT Integration Manager Use case

The integration manager’s workflow is not part of this article. Here, we focus on the local developer’s view and, thus, on the two use cases 1. “Get changes from main remote” (i.e. from the blessed repository) and 2. “Send changes to own remote”.

First, let’s have a look at the shorter “Send changes to own remote” use case. This is, where the user has carried out some changes, preferably in some non-master branches, merged them successfully into his master branch and now wants to share his success with other users. A combination the the two git commands commit and push will do it:

git commit -a -m "What I have done"
git push ssh://user@remote.srv/remoterepo.git
GIT - BPMN notation showing how to push to a remote repository

Fig. 3: GIT - BPMN notation showing how to push to a remote repository

However, in order to get changes from the blessed repository, it turned out that, for the secure daily work, changes should not be pulled to the master branch. Rather than that, a temporary branch should be created and switched to before pulling.

git remote add remoterepo ssh://user@remote.srv/remoterepo.git
git branch temp
git checkout temp
git pull ssh://user@remote.srv/remoterepo.git
git checkout master

Remember that the first command is required only once. Many developers new to this workflow have expressed their lack of understanding what’s behind those commands. Hopefully, the process shown in Fig. 4 may help:

GIT - BPMN notation showing how to pull from a blessed repository

Fig. 4: GIT - BPMN notation showing how to pull from a blessed repository

And that’s it, that’s all the magic. Using these two processes, we have totally decoupled developer’s from one another, i.e. the insufficiency of one does no harm to the others.

There are, of course, other ways to carry out these use cases, for example git fetch with a subsequent git merge into the master branch. For us, the git fetch workflow turned out to be more time consuming than a trial-and-error pull into a temporary branch, since in most cases, there is no need to review changes. In case there should be a need to do so, pulling into a temporary branch will reveal this necessity.

OAuth and Spring Security

While Spring Framework – and in particular Spring Security – provides many ways to deal with authentication and authorization, there are some new approaches that are becoming increasingly popular. As in most cases, the requirements of the cloud along with that of mulitenant applications have been the driving force of this evolution.

For example, while SSL is definitely a secure layer, many (if not most) home grown applications simply do not want to pay for a signed certificate (even less in face of the fact that such a certificate is mostly restricted to a single domain) and, thus, simply do not use SSL. Of course, this is worst, but still common practice.

Also, basic authentification is, presumingly with respect to its simplicity, still widespread. However, basic authentification in combination with a non-secure transport layer is a security black hole.

And finally, with SaaS rising, comfortable single sign-on in a multitenant environment must be considered in modern software design. Latter issue, cloud based single sign-on, is supported by the Spring Security (see ref. manual).

There are some more requirements emerging from the evolving cloud: for example, RESTful web services as part of asynchronous data transfer need to be secured on user level. While such scenarios can definitely be realized with the Spring Security, it definitely focuses on securing classic synchronous data transfer and flows (for instance, I would rather not choose Spring Web Flow to implement the flow of an highly AJAXian web application). In order to implement flows based on highly asynchronous communication between the client and server, there is definitely some hacking to do (see e.g. this tutorial).

However, the most important issue in times of millions of home grown smartphone apps is sharing credentials with such a client. Using same password over and over again, because you cannot remember millions of different passwords? Of course, this is worst, but still common practice. Now, what if your credentials are misused by your app? Wouldn’t it be much better, if you would not share your credentials with the client at all?

OAuth is an open protocol to allow secure API authorization in a simple and standard method from desktop and web applications. It has been developed with most of the issues that emerged from cloud-based authentification and authorizastion in mind. Furthermore, it is being used by global players like Digg, Jaiku, Flickr, Twitter, and developers of OAuth are hopeful to see Google, Yahoo, and others soon to follow. With so many heavy weight service providers relying on OAuth, it may definitely be considered as quasi standard. Unfortunately, Spring Security is not (yet) shipped with out-of-the-box support of OAuth, although I am pretty sure that the extremely capable Springsource team will deliver Spring with OAuth support as soon as possible.

For those who cannot (and should not) wait, a promising approach is described in OAuth for Spring Security. The purpose of this project is to provide an OAuth implementation for Spring Security. I have tested their implementation, and hereby I strongly recommend their approach. For me, the most striking advantage of this design is the combined power of both, OAuth and Spring Security. While you still have the comfort of Spring and its AOP framework, you have implemented the security of OAuth.

Follow

Get every new post delivered to your Inbox.