Everything is broken: Technology

Effectively using method and callee in Ruby

2017-02-19T01:00:00+01:00

Ruby provides many useful methods out of the box which allows for some very effective programming techniques. Today, we are taking a look at the __method__ and __callee__ helper methods and how they can help us produce DRY code.

Generally, both methods return the name of the currently running method as a Symbol. Using these methods, we can access the current method name without requiring us to duplicate the name in our code.

Now let’s have a look at them in action. Consider the following example where we create a Greeter class which allows us to give personalized greetings:

class Greeter
  def initialize(name)
    @name = name
  end

  def greetings
    "#{__method__.to_s.capitalize}, #{@name}!"
  end
end

greeter = Greeter.new('Ben')
greeter.greetings
# => "Greetings, Ben!"

As you can see, using the __method__ helper we don’t have to duplicate the name of the method in our code, thus keeping it DRY. In case we later decide to change the formality of the greeting and thus changing the method name, we wouldn’t also have to remember to change the method body to return the new greeting.

This with working and our software starting to get popular all over the world, we might decide to introduce a more familiar way to greet people using different localizations. If we are in Australia, people might prefer to use

Oi, Mick!

while in Sweden, it might be more appropriate to use

Hej, Anja!

The first approach to implement this could be to add multiple new independent methods, one for each greeting variant. However, this would quickly get out of hand and would effectively duplicate lots of code.

Since we are already using __method__ in our implementation, we could try to leverage this and use aliases instead.

class Greeter
  def initialize(name)
    @name = name
  end

  def greetings
    "#{__method__.to_s.capitalize}, #{@name}!"
  end
  alias oi greetings
  alias hej greetings
end

Now, when calling one of the alias methods, it turns out that unfortunately (for our use-case) __method__ always returns the name of the actual method, completely ignoring the alias we used:

Greeter.new('Mick').oi
# => "Greetings, Mick!"

Greeter.new('Anja').hej
# => "Greetings, Anja!"

Fortunately, there is a very similar helper method named __callee__ which helps us solve our use-case.

class Greeter
  def initialize(name)
    @name = name
  end

  def greetings
    "#{__callee__.to_s.capitalize}, #{@name}!"
  end
  alias oi greetings
  alias hej greetings
end

Greeter.new('friend').greetings
# => "Greetings, friend!"

Greeter.new('Mick').oi
# => "Oi, Mick!"

Greeter.new('Anja').hej
# => "Hej, Anja!"

Using the __callee__ helper, we can get the name of the current method exactly as it was called. For normal methods, this returns the same name as __method__. Once we use methods aliases however, the returned value differs since __callee__ always returns the name of the method as we actually called it, whichever alias that might be.

Since both helper methods are provided by Ruby’s Kernel module, they are directly available in about all Ruby objects. Using them, we can keep our code nice and DRY but still add new functionality with just one line of code without having to change any existing methods.

The post Effectively using __method__ and __callee__ in Ruby appeared first on holgerjust.de.

Detecting default arguments in Ruby

2016-12-27T21:08:00+01:00

When defining a method in Ruby, you can define default values for optional parameters. When calling the method, Ruby sets the default value to the local variable as if the user would have provided this argument. This automatism is really useful to support optional parameters with sensible defaults without having to think much about this. It even works exactly the same with the new keyword arguments introduced in Ruby 2.0.

Given this method:

def debug(required, optional = 'value')
  puts "required: #{required}"
  puts "optional: #{optional}"
end

When calling the method, you get the usual results:

debug('foo')
# require: foo
# optional: value

debug('bar', 'overwritten')
# require: bar
# optional: overwritten

A commonly used default value for optional parameters is nil. You can however use any value you like, including the result of a method call. This works great most of the time. That is, well, until you really have to test if an argument was actually provided by the caller or not since any value (including nil) would be considered valid.

A real-world example of such a method is Hash#fetch. This method allows to fetch the value for a given key from a Hash object. If the key is in the hash, its value is returned. If the key could not be found however, the method will either return a given default value or raise an error if no default value was provided. Since any Ruby object including false or nil are potentially valid default values, we can’t just define a static default value here:

hash = {foo: :bar}
hash.fetch(:foo)
# => :bar
hash.fetch(:missing)
# => KeyError: key not found: :missing
hash.fetch(:missing, 'my default value')
# => "my default value"
hash.fetch(:missing, nil)
# => nil

Luckily, there are several idioms which allow to detect whether there was actually an argument passed to an optional parameter which I will describe below.

A Special Flag Variable

The first and most self-contained option is to use a guard flag in the method definition.

def with_flag(required, optional = omitted = true)
  puts "required: #{required}"
  puts "omitted: #{omitted.inspect}"

  if omitted
    puts 'no optional given'
  else
    puts "optional: #{optional}"
  end
end

Now when calling this method and actually passing a value to the optional parameter, it will be set normally. The default part, i.e. omitted = true will not be executed here. Instead, the omitted paremeter will be initialized with nil.

On the other hand, when omitting the argument and calling the method as with_flag('value'), the default part will be executed and omitted as well as optional will be set to true. This allows to determine whether an argument was passed by checking the omitted flag. If it is nil, an argument was passed. If it is the final default value (true in our example) it was however omitted:

with_flag('foo')
# required: foo
# omitted: true
# no optional given

with_flag('foo', 'value')
# required: foo
# omitted: nil
# optional: value

Special Default Value

Another option is to use a different special default value which we have determined to never represent a valid value. Again, this is only required if we can not come up with a “normal” default value like nil, 0 or an empty array or hash.

In our example, we define a constant called UNDEFINED with an empty Object instance and use it as a default value. Since the object is not equal to any other value, you can use it as a special flag to determine that no value was passed and just compare the argument to the same UNDEFINED object.

UNDEFINED = Object.new
# => #<Object:0x007fd87284af38>

def with_value(required, optional = UNDEFINED)
  puts "required: #{required}"

  if optional.equal?(UNDEFINED)
    puts "no optional given: #{optional}"
  else
    puts "optional: #{optional}"
  end
end

When calling the method, the comparisons work as expected. As you can see, the default value is initialized with the UNDEFINED constant when not passing the optional argument and thus is considered to be omitted.

with_value('bar')
# required: foo
# no optional given: #<Object:0x007fd87284af38>

with_value('foo', 'value')
# required: foo
# optional: value

Using a Splatted Parameter

A third option is to use a splat parameter in the method’s definition. This accepts an unlimited number of optional arguments and provides them to the method body in an array.

def with_splat(*args)
  # Enforce the actually intended method interface by raising an error if too
  # many arguments were passed to the method.
  unless 1..2.cover?(args.size)
    raise ArgumentError, "wrong number of arguments (#{args.length} for 1..2)"
  end

  puts "required: #{args[0]}"
  if args.size == 1
    puts 'no optional given'
  else
    puts "optional: #{args[1]}"
  end
end

By inspecting the args array, we can test whether we got an optional argument or not. If the array is has exactly 1 element, no optional argument was passed. If it has 2 elements, we use the second one as our optional value.

This variant more or less resembles what Ruby itself does in its implementation of the Hash#fetch method for example. Since the method is implemented in C, arguments are extracted and validated from the ARGV array passed to the method which resembles our args array.

Which variant to use?

Which option to use depends a bit on which traits of the code should be emphasized.

The first option with the omitted flag can read a bit nicer in the method body and does not require the permanent allocation of an additional object to represent the empty default value. However, the code and its detailed semantics can be a bit surprising for people not accustomed to this pattern. Which can result in people misusing the method.

The second option with the special default value however is pretty clear and follows the common pattern of assigning a known default value to a parameter. By defining our own null value, we can elegantly work around the issue of nil being a valid intended value. However, we always need to be aware of the special null value and often have to handle it in special way to e.g. pass it as nil to other methods. Since this pattern should be used only if nil itself is not a suitable default value, this would be required anyways though.

The third option of using splat parameters looks rather simple from the outside and doesn’t rely on static values or the intricacies of argument assignments in Ruby. However, it has the huge downside that the method interface isn’t clearly defined anymore. Just from looking at the method definition, we can no longer see how many arguments the method accepts but have to look into the method body. We even have to rely on custom error handling to check the number of passed arguments.

As such, for one-off methods, the first option is quicker to write and has clear-enough semantics to experienced Ruby developers. The second option provides a more traditional method interface for the potential cost of a bit more checking in the method body. With a well-named default value, the intention becomes clear just from looking at the method definition. The third option however does not resemble idiomatic Ruby anymore but looks more like C or Perl where we have to deal with numeric indexes instead of well-named variables and arguments. as such, this option has a clear disadvantage to the others since it is much less intention-revealing.

With that in mind, which ever variant you use, try to use one of these methods consistently throughout your module to allow people reading your code to recognize the pattern and thus to reduce the cognitive load required to understand what the code does.

Most of the time, you should try to rely on “normal” default values. Using one of the techniques described in this article should generally be your last resort since they will never be as clear as a simple method definition with simple default values.

Update 2016-12-28: After some discussion on Facebook it became clear that the motivation for why you would need these techniques is not clearly described. As such, I have added the real-world example of Hash#fetch. I also added the third option of using a splatted parameter.

The post Detecting default arguments in Ruby appeared first on holgerjust.de.

Speeding up Git at Planio

2016-02-05T01:00:00+01:00

This is a story about how a significant increase in the number of Git repositories at Planio resulted in a noticeable service slowdown and how we were able to not only fix this but to provide a sustained speedup of the whole service.

At Planio, we have always provided unlimited Git repositories as part of our Redmine hosting product. In fact, one of the first open source plugins to provide full Git hosting integration to Redmine was developed by Planio and subsequently formed the basis of most of the currently popular plugins.

About 6 years later, our internal codebase has changed significantly due to increased customer demand but the basic architecture of our Git service was still the same. At Planio, access to Git is provided over SSH where permissions are enforced by our internal fork of Gitosis. It has served us well in the past and while the project is not maintained by its original authors anymore, we still use our own patched version due to its small footprint and its general absence of features we don’t need anyway.

With Gitosis, access to repositories is provided based on a single configuration file which lists the access permissions of all users and their repositories. It also handles the management of SSH keys which are concatenated to a single authorized_keys file for the SSH server. Each time, someone created or deleted a repository on Planio or when someone uploaded a new SSH key, we start a background job to synchronize the Gitosis configuration file with the new data.

Unfortunately, it all broke down once we started to create new Git repositories for all new Planio accounts by default to make it easier to use Planio with the awesome Sparkleshare synchronisation tool. Before this change, only users who explicitly wanted to use a Git repositoriy created one in their account, resulting in a “manageable” number of repositories overall. With this change however, we now had almost doubled the number of configured Git repositories in a couple of weeks’ time.

Unfortunately, this resulted in a serious slowdown for many Git users while our backend servers where peaking at a system load of 120 with most of the time spent in Gitosis before any actual Git interaction. Not good, not good at all…

Digging into the code, I quickly identified the lookup method in Gitosis which determines which repositories a user has access to as the main culprit. It turned out that the method loops over the whole list of repositories multiple times, resulting in a algorithmic complexity of O(2n²) in our case. As we have about doubled the number of configured repositories, the lookup now took four times as long for each single Git operation. With only limited CPU power available, the processes began stepping on each others toes waiting for CPU time on their own. And as we were constantly adding new Git repositories, this problem only worsened over time.

The solution to this problem came with inspiration from some old pull request I started on the now defunct ChiliProject which was intended to unify the authentication and authorization implementations of external services like Subversion. If we can provide a simple API in Redmine which can quickly tell us if a certain user has the permission to read or write a repository, we can use this in Gitosis with a single HTTP call per Git operation.

Fortunately, we already used sane conventions to name repositories and users in the form of uniquely named SSH keys in Gitosis. This allows us to efficiently determine the affected Redmine user and project for each Git operation. As we have all the code to check for arbitrary permissions already in place in Redmine, all the new API endpoint has to do is to identify the correct user and check their permission in the respective project. This is a very common and quite optimized task in Redmine - even more so when utilizing the builtin Rails cache to improve response times for repeated authorization requests.

On Gitosis’ side, I was able to almost completely replace the existing authentication mechanism with a single HTTP call to Redmine and just checking the response. Besides being overall much faster, it also reduces latency during repository creation as users don’t have to wait anymore until the Gitosis config file was updated. But the best result? With this change, I was able to remove about half of the overall codebase in Gitosis. Seeing this at the end of a code review warms every developer’s heart. No code is better than no code.

30 files changed, 283 insertions(+), 1924 deletions(-)

Developing the API in Redmine and integrating it into Gitosis took me about 3 days. This included extensive correctness and performance tests to ensure that we do in fact enforce the defined permissions and can do this fast. In the end, we are now able to respond to an authorization request in about 300 ms end-to-end which is about 20 times faster than we were able to pull off during peak usage last week with the old authentication mechanism.

The hard work on our Git hosting infrastructure pays off: Overall Git access is now 20x faster than last week! https://plan.io/de/subversion-hosting-und-git-hosting/
— Planio (@planio) February 2, 2016

Directly after the deployment of the new authentication mechanism, the load of the backend servers dropped back from about 40 to just below 1, which is nice because we now get much less of these alarming monitoring pings about melting servers.

This post originally appeared on Planio’s blog on February 5, 2016.

The post Speeding up Git at Planio appeared first on holgerjust.de.

FrOSCon 2010: Redmine, und dann?

2010-09-29T17:16:24+02:00

Am 21. August 2010 war mal wieder FrOSCon in St. Augustin (bei Bonn). Und ich war dabei, vor allem um einige Open Source Projekte näher kennen zu lernen, Leute zu treffen und vor allem, um dem Redmine-Vortrag von Felix Schäfer zu lauschen.

Aus Gründen war der Felix leider verhindert, sodass ich mich spontan bereit erklärt habe, den Vortrag zu übernehmen. Damit hatte ich meinen ersten Talk auf einer Konferenz. Und mit nur ca. 3 Stunden Vorbereitung war der dann sogar ganz okay.

Die Aufzeichnung des Vortrags ist jetzt bei CCC-TV online.

Redmine ist installiert, ein paar Projekte sind angelegt, und die Defaulteinstellungen scheinen gut zu klappen. Alles läuft gut, ein paar Kleinigkeiten scheinen allerdings noch zu fehlen, aber was? Redmine eignet sich nicht nur hervorragend zum Verwalten von “einfachen” Softwareprojekten, sondern dank der hohen Anpassbarkeit des System zu komplexeren oder gar nicht softwarebezogenen Projekten.

Aufzeichnung FrOSCon / cc-by-nc-sa

The post FrOSCon 2010: Redmine, und dann? appeared first on holgerjust.de.

Cross-browser CSS gradient

2010-07-26T11:22:00+02:00

Recently, I released a new version of the Redmine Checkout plugin. This release sports a nifty protocol selector with buttons styled entirely in CSS (as good as it gets). To be able to support as many browsers as possibly while not having to fall back to pixel graphics I had to apply some tricks which I want to describe here.

The buttons take most of their appearance from a background gradient with a light color at the top and a darker color at the bottom. This gives them some kind of three-dimensional effect compared to the plain-colored background. We are going to style the unselected button on the right. The left selected button is styled equivalent with just some different colors.

An unselected standard button is styled as follows:

ul#checkout_protocols li a {
  background-color: #eee;
  background:  url(button.svg) 0 0 no-repeat; /* Opera  needs an "image" :( - using svg for this so it will scale properly without looking too ugly */
  background: -khtml-gradient(linear, left top, left bottom, from(#f8f8f8), to(#ddd)); /* Konqueror */
  background: -webkit-gradient(linear, left top, left bottom, from(#f8f8f8), to(#ddd));   /* Webkit (Chrome, Safari, ...) */
  background: -moz-linear-gradient(top,  #f8f8f8,  #ddd); /* Gecko (Firefox, ...) */
  filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#f8f8f8', endColorstr='#dddddd'); /* IE 5.5 - 7 */
  -ms-filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#f8f8f8', endColorstr='#dddddd'); /* IE 8 */
  position: relative;
}

As you can see, there are a multitude of rules which each target a specific browser. This is required as there is no standard defined on gradients yet. However every major browser supports a technique for this – just in its own syntax.

The first rule on line 2 (and also line 3 as seen later) works as a default here. It is used in browsers which do not support one of the following rules. It forces a background color which does not look too bad and at least keeps the GUI element usable. Lines 3–8 each target a specific browser family to use a gradient instead of the simple background.

KHTML (Konqueror) and Webkit (Chrome, Safari, …)

Let’s start with line 4 and 5. These rules target KHTML browsers (like Konqueror) and the similar Webkit browsers (Chrome, Safari, …) respectively. The rules are structured as follows (more information can be found in the Safari documentation).

linear — The gradient type. Can be one of linear or radial
left top — The starting point of the gradient. This is a X-Y coordinate.
left bottom — The end point of the gradient. This is a X-Y coordinate.
from(#f8f8f8) — The start color.
to(#ddd) — The end color.

Gecko (Firefox, Mozilla, …)

Line 6 targets Gecko-based browsers like Firefox, Thunderbird or Mozilla. These define the gradient type inside the actual rule name. So -moz-linear-gradient defines, well, a linear gradient while -moz-radiant-gradient defines a radiant gradient. We obviously use -moz-linear-gradient here.

top — Starting point of the gradient.
#f8f8f8 — Start color.
#ddd — End color.

Internet Explorer

Line 7–9 focus on Internet Explorer. Here we use filters which are very old IE-only features, originally invented to allow DHTML animations. They are rather slow and show strange behavior sometimes, but it the only way to get gradients to IE. On the other hand, these even work on IE 5.5. The HTML element must have layout. So we use position: relative in line 9. If you omit this, it is showing some really strange renderings. The parameters of the filters should be rather self-explaining. As the filter syntax has slightly changed from IE7 to IE8 we include both variants here. Additional documentation is available from Microsoft.

Opera

And finally there is Opera. This browser is targeted in line 3. Unfortunately Opera does not support the concept of a gradient out of the box, so we have to develop a fallback here. Fortunately though, it supports SVG which allows us to define the gradient in an XML format to still benefit from the vector definition and not having to fallback to a pixel representation. As this is a fallback, it must be defined atop of the other rules which then overwrite this rule if one them is supported. If the SVG rule was put at the bottom, it would have a higher priority and all browsers would attempt to use it.

This technique, however, allows us to even target browsers which do not match one of the explicitly supported browsers but do support SVG.

The referenced SVG is rather simple:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="100%" height="100%" version="1.1" xmlns="http://www.w3.org/2000/svg">
  <defs>
    <linearGradient id="gradient" x1="100%" y1="100%">
      <stop offset="0%" style="stop-color:#ddd; stop-opacity:1" />
      <stop offset="100%" style="stop-color:#f8f8f8; stop-opacity:1" />
    </linearGradient>
  </defs>
  <rect width="100%" height="100%" style="fill:url(#gradient)"/>
</svg>

Note that the start color is defined on offset="100%" and the end color on offset="0%".

The post Cross-browser CSS gradient appeared first on holgerjust.de.

How to compile Postfix + SASL + LDAP on Opensolaris

2010-06-14T20:44:00+02:00

Currently, Opensolaris does not provide a Postfix package. Although there exist packages on blastwave and on OpenCSW they are either outdated or do not play well together.

Fortunately, Ihsan Dogan did create a script to create Postfix packages from scratch as well as some precompiled packages. Unfortunately, these packages miss SASL support. So I was in need to compile these myself.

You will obviously need the Postfix sources and the package script:

wget http://de.postfix.org/ftpmirror/official/postfix-2.7.1.tar.gz
gunzip -c postfix-2.7.1.tar.gz | tar -xf -

wget http://ihsan.dogan.ch/postfix/downloads/makePostfixPkg.sh
chmod +x makePostfixPkg.sh

cd postfix-2.7.1

Since Opensolaris b130, NIS+ was removed from the system. As Postfix does not know that, it will not compile as it defines a dependency to it. However, this can be disabled by simply applying the following patch:

--- src/util/sys_defs.h 2010-06-02 01:56:57.000000000 +0200
+++ src/util/sys_defs.h 2010-06-14 22:08:35.596113543 +0200
@@ -400,7 +400,6 @@
 #define DEF_DB_TYPE  "dbm"
 #define ALIAS_DB_MAP "dbm:/etc/mail/aliases"
 #define HAS_NIS
-#define HAS_NISPLUS
 #define USE_SYS_SOCKIO_H   /* Solaris 2.5, changed sys/ioctl.h */
 #define GETTIMEOFDAY(t)  gettimeofday(t)
 #define ROOT_PATH  "/bin:/usr/bin:/sbin:/usr/sbin:/usr/ucb"

Just put that patch into a file called nisplus.patch and patch the code:

1	patch -p0 < nisplus.patch

(found on estibi’s Solaris blog)

Before actually compiling Postfix, we need some packages:

# First install the sunstudio compilers and some additional
# development tools
pkg install sunstudio12u1 object-file

# ...and some additional libraries and tools
pkg install libsasl pcre

Now we can generate the script compile and generate the SRV4 package. We will tell the compilers to include the default Cyrus SASL library for client authentication as well as the Dovecot library which I will use later to connect both servers and authenticate SMTP users.

# Clean up first and after failed attempts
make tidy

# Generate the makefile
make makefiles CCARGS='-DUSE_TLS -DHAS_LDAP \
-DUSE_SASL_AUTH -DDEF_SERVER_SASL_TYPE=\"dovecot\" \
-DUSE_CYRUS_SASL -I/usr/include/sasl'
AUXLIBS="-L/usr/lib -lsasl -lssl -lcrypto -lldap"
CC=/opt/sunstudio12.1/bin/cc

# Build
make

# Create the package if the build succeeded
../makePostfixPkg.sh

The makePostfixPkg.sh script will create a Solaris package named something like CNDpostfix-2.7.1,REV=100614-SunOS5.11-i386.pkg inside the Postfix directory. This package can then be installed like this:

# make sure you removed the default Sendmail package first if it installed
pkg uninstall sendmail

# install the package
pkgadd -d CNDpostfix-2.7.1,REV=100614-SunOS5.11-i386.pkg CNDpostfix

# Configure the package to your needs. Then enable the service
svcadm enable svc:/network/postfix:default

The post How to compile Postfix + SASL + LDAP on Opensolaris appeared first on holgerjust.de.

Sane Opensolaris Settings

2010-02-05T13:46:00+01:00

Opensolaris has done some huge steps towards being usable by a normal person. Sadly there are still some things lacking sane defaults which I try to provide here. I will try to update this post if I stumble over more of these hiccups.

Correct colors on exit of an ncurses program

If an ncurses program (like nano) exits, the default xterm-color does not properly restore the colors of the terminal. The background color is shown in a dark gray. For a quick relieve you can issue a short

tput rs1

As this is rather cumbersome, I think it is better to adjust out terminfo definitions.

TERM=xterm-color infocmp > /tmp/xterm-color.src
sed -i -e 's/op=\\E\[100m,/op=\\E\[m,/' /tmp/xterm-color.src
pfexec tic -v /tmp/xterm-color.src
rm /tmp/xterm-color.src

The solution is from the Opensolaris Bug, the rough steps from Peter Harvey.

Fixing some key bindings

By default some essential key bindings do not work properly. This can be fixed by just reassigning them. The following statement has to be run as root.

cat >> /etc/profile <<BASH
# home key
bind '"\e[1~":beginning-of-line'
# del key
bind '"\e[3~":delete-char'
# end key
bind '"\e[4~":end-of-line'
# pgup key
bind '"\e[5~":history-search-forward'
# pgdn key
bind '"\e[6~":history-search-backward'
BASH

You have to logout and login again for these settings to take effect. Alternatively you could just enter the individual bind statements into your current terminal.

The bindings are from Epiphanic Networks’ Wikka.

The post Sane Opensolaris Settings appeared first on holgerjust.de.

Vertikales Ausrichten von LaTeX-Blöcken

2008-01-13T23:46:00+01:00

Der oder die Eine oder Andere wird vielleicht mal drauf stoßen, dass man in LaTeX-Tabellen die vertikale Ausrichtung von Elementen nicht direkt bestimmen kann. Das ist sehr ärgerlich, wenn man zum Beispiel Grafiken in einer Tabelle setzen will und sie vertikal zentriert in den Zellen ausrichten will.

Hier hilft eine sogenannte Minipage. Das ist eine syntaktische Möglichkeit, eigene Boxen zu definieren, an denen man dann definieren kann, welche Ausrichtung ihre Inhalte gegenüber der Grundlinie haben. Das kann dann etwa so aussehen:

\begin{tabular}{c|c}
  Links & Rechts \\
  \hline
  \begin{minipage}[c]{5cm}
    \begin{center}
      \includegraphics[width=4.5cm]{img/klein}
    \end{center}
  \end{minipage} &
  \begin{minipage}[c]{5cm}
    \begin{center}
      \includegraphics[width=4.5cm]{img/sehr_hoch}
    \end{center}
  \end{minipage} \\
\end{tabular}

Der interessante Teil ist das c in eckigen Klammern nach \begin{minipage}. Hier kann man die vertikale Ausrichtung als top, center oder bottom angeben.

Weitere Beispiele und eine genauere Beschreibung findet sich auch in The Not so Short Introduction to LaTeX 2e im Kapiel 6.6.

Nachtrag

Eine weitere (von mir jetzt nicht getestete) Möglichkeit, die auf dem Koma-Script basiert findet sich beim KOMA-Script documentation project.

The post Vertikales Ausrichten von LaTeX-Blöcken appeared first on holgerjust.de.

Zeitsparen mit Word

2008-01-12T14:17:00+01:00

Es sind die kleinen Dinge, die einem viel Zeit sparen können. Bei Word geht es (zumindest, wenn man Vorlagen einsetzt) häufig darum, alle Felder mit z.B. Referenzen zu aktualisieren.

Leider wird das von Microsoft nicht direkt ermöglicht. Es kann natürlich auch sein, dass ich es nur nicht gefunden habe.

Solange man keine Felder in Kopf- und/oder Fußzeilen einsetzt reicht ja ein klassisches Strg+A gefolgt von F9, was sich aber nur auf den “normalen” Text auswirkt.

Möchte man hingegen wirklich alle Felder eines Dokuments aktualisieren, dann kann man das folgende einfache Makro hernehmen. Es ist getestet auf Word XP und 2003.

Sub AlleFelderAktualisieren()
    '  Update All Fields
    Dim Part As Range
    For Each Part In ActiveDocument.StoryRanges
        Part.Fields.Update
        While Not (Part.NextStoryRange Is Nothing)
            Set Part = Part.NextStoryRange
            Part.Fields.Update
        Wend
    Next

    ' Update Table of Contents
    Dim TOC As TableOfContents
    For Each TOC In ActiveDocument.TablesOfContents
        TOC.Update
    Next
End Sub

The post Zeitsparen mit Word appeared first on holgerjust.de.