Duncan Mac-Vicar P.

Reading a commit from DHH I found out a syntax I was not aware of.

Instead of doing:

[1,2,3,4,5,6,7,8,9,10].select { |x| x.even? }

You can do:

[1,2,3,4,5,6,7,8,9,10].select(&:even?)

When I asked in #rubyonrails irc channel about this syntax, I got enlightened: The first part is obvious: last argument starting with & is interpreted as a Proc and equivalent to passing a block, so it is not a &: operator but & and a symbol. How does the symbol work?

According to the people in the channel, it is rails magic. When I said that it works for me in irb I was told I must be running ruby 1.9, which I am not. After some discussion we realized this magic is in ruby 1.8.7 too.

The magic is of course, just Symbol#to_proc method

I was very happy that Rails Engines got merged in Rails 2.3. However I never liked that engines did not support overlaying static assets like they do with controllers, models and views. Even worse, the discussion was around “mirroring” the engine’s assets into the application public/ directory (like you can see in this railcast).

I imagined that doing something more transparent would be non-trivial. But I never asked myself why. When mentioning this limitation to Daniel when explaining how we use engines in our code, he asked the magical question: “Why?”.

I have been looking at Rails’s Rack support recently. I love Rack. And if you see how Rails builds its complex pieces over such simple components based on Rack, you realize how good Rack is for the Ruby community as a base component.

So, I tried the very first though: Create a Rake middleware called StaticOverlay that is initialized with various overlay directories. When the middleware is called it will look for the file in the overlays, and if it finds it in one, it will serve it (using Rack::File), if not, it just call the application (or next middleware in the chain).

Once I put the rack middleware together it worked out of the box, so I started a thread in rails core list to find out whether this would be a valid approach to hack a real patch and add support for this in Rails itself.

Together with the launch of SUSE Studio 1.0, an alpha demo of WebYaST was also included in the Appliance Kit preview. We talked about WebYaST earlier this year. The demo includes small functionality like setting the system language, system time, patches/updates and general status of your appliance.

WebYaST mission is to add value to your appliance by providing the basic setup requiring only a web browser. The idea is that you build your appliance with Studio and include WebYaST so you can perform setup, configuration and basic monitoring.

The WebYaST demo is available as an appliance (built with SUSE Studio) on the Novell Appliance Program page. Advanced users can follow the YaST:Web repository on the openSUSE Build Service.

Haven’t tried SUSE Studio yet? Here is a nice demonstration video.

If you are an ISV, you may also want to checkout the upcoming SUSE Lifecycle Management Server, everything you need to serve your appliance customers with your application plus operating system updates.

Packager’s favorite dashboard got a new version. Most patches were contributed by Michael Andres.

• follow links to a package with different package name.
• adapt to changed API to retrieve submitrequests.
• support ‘changes=1′ in ini-inifile to print changelogs per section (like -c)
• osc no longer takes the md5 as revision.
• cleanup changelog diff temp files
• suppress changelog diff if source does not provide changes ( like obssr)
• let changes diff consider only repos that actually provide changes.

Get it from [the build service], or visit the home page here. You can read the introductory post here.

Available for openSUSE Factory in my home project. I also submitted to the KDE:KDE4:Factory:Desktop project where you may find it built for older releases using a newer KDE.

Changes:

• Some connection fixes
• The idle status icon is now shown
• Basic user info widget (bug #198286)
• Show contact status message! (bug #198284)
• build system improvements
• qjson 0.6.x is now required

Known bugs:

• The plugin crashes when exiting Kopete. Some weird stuff with “myself” contact which seems to be deleted twice

Note: This plugin is not associated with Facebook in any way.

Get the deb package from the developer release site.

Unpack the deb:

ar x google-chrome-unstable_current_i386.deb 
lzma -d data.tar.lzma 
tar xpvf data.tar

Now you got a opt directory in the current directory with the full tree. Go to the Chrome directory.

cd opt/google/chrome

Symlink the libraries:

ln -s /usr/lib/libnss3.so ./libnss3.so.1d
ln -s /usr/lib/libnssutil3.so ./libnssutil3.so.1d
ln -s /usr/lib/libsmime3.so ./libsmime3.so.1d
ln -s /usr/lib/libssl3.so ./libssl3.so.1d
ln -s /usr/lib/libplds4.so ./libplds4.so.0d
ln -s /usr/lib/libplc4.so ./libplc4.so.0d
ln -s /usr/lib/libnspr4.so ./libnspr4.so.0d

Run it and enjoy!. Be sure to read about privacy features of this preview release.

LD_LIBRARY_PATH=$PWD ./google-chrome

Ark Linux is becoming the first third-party distro other than openSUSE to adopt ZYpp as its package manager.

As you may know, are working on making YaST functionality accessible via the web. With this we mean not only browser. The current prototype has two parts: a generic web service (REST like API) and a web browser client.

Stefan Schubert announced last week a new snapshot for developers. You can find packages in the build service project. The packages are named yast2-webservice and yast2-webclient.

This is very early code. It is not fast, and the web client is not yet using all user interface possibilities that ajax gives, but there are we going .

If you are an experienced user, and you get it running, you may be interested in getting it running from source code by reading our development web page. Both the webservice and the webclient are rails applications. Developing modules is also easy! Just show up in irc (freenode) #yast.

Last week I blogged about Facebook support for Kopete, just after I was able to see my buddies for first time on the screen.

Since then I have made some improvements to message handling and other code cleanups. The code is now available in a git repository at github.

As KDE’s svn trunk is frozen, I will keep it there for now.

You can get packages for openSUSE Factory (version 0.1.2). I gave up trying to build it for openSUSE 11.1, as Kopete API has changed quite a bit. However the package may build on 11.1 plus the KDE 4.2+ repositories. You need libqjson from Flavio Castelli installed (or -devel package if you want to build it).

Roadmap for next 0.1.3:

• Add caching to avoid downloading the pictures every 3 minutes.
• More bugfixes

Roadmap for later:

• Look into adding , searching, and other stuff.

Be aware. This is weeks-old-code. It has not been tested much and has lot of debug messages. Use it if you are a early adopter only.

So, I have been working some weeks on this, and today I reached the first “usable” point. Screenshot:

As you may know, Facebook has a chat service. For me at least is slowly becoming the place where I have more people talking to me, and as you may also guess, the value of social systems is very tied to the number of users.

Sadly, Facebook guys where not smart enough as the Google guys and brought yet another damn protocol to this protocol overpopulated world. Then came the worst part. They announced something that was not there and promised Jabber support. One year later nothing has yet happened.

For a such popular service, one starts to think whether waiting another year is worth for a protocol that is so popular. As I wanted it myself now, at some point I decided I was willing to implement it even if a Jabber version was available later.

We already have the problem that users expect to see Google talk in the Kopete list, because developers don’t figure out that grandma does not know what Jabber/XMPP is. So a good improvement would be adding the concept of “services” where we could add a protocol by just saying “it is just jabber, but with this server settings, this logo and this name”. That path would allow for a easy move to other XMPP protocols later.

But for Facebook, no more wait. Yesterday I was able to use it for first time to chat, so I am blogging about it.

Next steps:

• Add more error handling
• Fix a bug in the contacts status when they go offline
• Put it into kopete or playground svn
• Make an openSUSE package
• Cleanup. I started over the testbed plugin and it added some stuff that probably I don’t need
• Proxy support. I coded the engine using QNetworkAccessManager so it is KDE independent. Only the Kopete plugin is KDE based, so I haven’t looked into proxy support and other stuff

Other stuff with less priority:

• Adding contacts from the client
• Configuration (there is no much to configure)