The times for Ubuntu have never been more exciting. Cloud, server, desktop, laptop, TV, tablet, phone – everything runs Ubuntu or is soon going to. This makes developing Ubuntu very special, because fixes which go into Ubuntu in one place will benefit all form factors and all circumstances where it’s used. By improving Ubuntu you make millions of people around the globe happy.

During every 6 month release cycle we run Ubuntu Developer Week. It’s back and we’re going to have it from 29th January to 31st January. During the event we will have online sessions where seasoned Ubuntu developers introduce you to their respective area of expertise or to Ubuntu Development in general.

We will have many great sessions, from hands-on introduction to packaging and Ubuntu development to talks about how to quickly get involved in certain teams and interact with other projects. We will talk about tools and infrastructure, fixing bugs, finding memleaks, working with apps, create Ubuntu images and much much much more. This is the best opportunity to get a feel for how Ubuntu development works, get to know people and ask all the questions you might have.

I talked to a few session hosts, read below what they had to say.

Martin Pitt

Martin Pitt, who will talk about Automated Testing, says: “We have been, and are changing the Ubuntu development process to employ automated testing and avoid introducing regressions, and to improve confidence, focus, and development speed. In the first talk I will give an overview about the various kinds of tests that we do, so that you know where to watch out for failures and get debugging information. The second talk focuses on how to write tests, i.e. which technologies are available for e.g. hardware and GUI related behaviour or system-wide integration checks.”

 

Stefano Rivera

Stefano Rivera, who will talk about Upstreams and Debian in particular, said: “So, working effectively in Ubuntu means also working with the teams and people upstream who wrote the software we distribute. I’ll talk about why this is important, when it’s necessary, and how to go about it. In particular, our most important upstream is Debian. Debian has a rather unusual (though powerful) bug-tracker. We’ll cover finding, submitting, and modifying bugs on it.”

Chris Wilson

Chris Wilson, project leader of the Hundred Papercuts Team, says: “Unity may be the shiny new thing that everyone loves, but style without substance is only so much fluff, and the substance of Ubuntu is still its GTK-based apps. Once Hundred Paper Cuts focuses it’s attention on that substance, rubbing out the little annoyances that get under our skin every day we’re using Ubuntu. This session will introduce you to the project, how it works, and how to get involved. If you want to contribute to Ubuntu in a way that has the biggest impact on the quality of experience for the end user, then don’t miss this.”

 

Bhavani Shankar

Bhavani Shankar, said about his talk about patch systems: “Many a time we wonder how to integrate a particular fix a particular part of the code in a program and upload into repositories without having to change code each time by hand and making it clumsy. In this session I’m going to show how to use different patch management systems that are in practice now.”

About his talk about the app review process in Ubuntu he says: “In this session I’m going to explain the present workflow of reviewing apps and give an introduction into the new app dev upload process to automate reviews.”

The forum we use for this is IRC, as it makes it easy to interact for many people without losing track, you can easily copy/paste and we can save the logs as searchable docs afterwards. You join in by simply connecting to #ubuntu-classroom on irc.freenode.net.

Check out the schedule and find more info on the Ubuntu wiki. We hope to see you all there, please let you friends know too.

Since today, LaTeX-Community.org readers can use an online LaTeX compiler in the forum, provided by writeLaTeX.com, an online collaborative LaTeX editor with integrated rapid preview.

By a single click on a link above a code box, the reader will land in the editor which shows the code on the left side, and the output preview on the right side. Compilation is done in realtime.

Now it’s easier to support LaTeX users, especially if they would add a compilable minimal example to their problem. Even small code snippets would be wrapped to create a basic LaTeX document.

For more information and examples, have a look at the announcement.

Happy New Year for all!

The animated GIF image shows fireworks displayed with TikZ written by Chris Hughes aka cmhughes on TeX.SE. Follow the link to see further fireworks effects.

The code is:

\documentclass[tikz]{standalone} \usepackage{tikz} \usetikzlibrary{decorations.pathmorphing,decorations.shapes}   \begin{document}   \foreach \radius in {1,2,...,20} { \begin{tikzpicture} % background rectangle \filldraw[black] (-3,-3) rectangle (5,3); % skyline \filldraw[black!80!blue](-3,-3)--(-3,-2)--(-2.5,-2)--(-2.5,-1)--(-2.25,-1)--(-2.25,-2)--(-2,-2) --(-2,-1)--(-1.75,-0.75)--(-1.5,-1) --(-1.5,-2)--(-1.1,-2)--(-1.1,0)--(-0.5,0)--(-0.5,-2) --(0,-2)--(0,-1.5)--(1,-1.5)--(1.25,-0.5)--(1.5,-1.5)--(1.5,-2) --(2,-2)--(2,0)--(2.5,0)--(2.5,-2) --(3,-2)--(3,-1)--(4,-1)--(4,-2)--(5,-2)--(5,-3)--cycle; % moon- what a hack! \filldraw[white] (4,2.5) arc (90:-90:20pt); \filldraw[black] (3.8,2.5) arc (90:-90:20pt); % fireworks \pgfmathparse{100-(\radius-1)*10}; % red firework \ifnum\radius<11 \draw[decorate,decoration={crosses},red!\pgfmathresult!black] (0,0) circle (\radius ex); \fi % orange firework \pgfmathparse{100-(\radius-6)*10}; \ifnum\radius>5 \ifnum\radius<16 \draw[decorate,decoration={crosses},orange!\pgfmathresult!black] (1,1) circle ( \radius ex-5ex); \fi \fi % yellow firework \pgfmathparse{100-(\radius-11)*10}; \ifnum\radius>10 \draw[decorate,decoration={crosses},yellow!\pgfmathresult!black] (2.5,1) circle (\radius ex-10ex); \fi \end{tikzpicture} } \end{document}

The resulting PDF file can be cropped and converted using

pdfcrop myfile.pdf
convert -delay 20 -loop 0 -density 300 myfile-crop.pdf fireworks.gif

This Christmas tree has been written in LaTeX and TikZ by Alain Matthes. See the complete source code.

Every Ubuntu release gets an alliterative code name from Mark Shuttleworth. It is a composition of an adjective and an animal. The upcoming Ubuntu 13.04 has the code name “Raring Ringtail”. Since nearly the beginning, the code names follow the alphabetical order. We will reach the letter Z with Ubuntu 17.04 if no letters are skipped. Will we wrap then and begin with A again?

At UDS-R in Copenhagen, Mark Shuttleworth jokingly said between Jono Bacon’s introduction and Mark’s keynote speech, that vegetables will be used once we run out of letters. He proposed the code name for Ubuntu 18.04 LTS: Brilliant Broccoli!

Live syntax checking code in Emacs with flymake is extremely
useful. It’s quite easy to use for syntax checking scripting
languages or for running code analysis tools in the
background. Flymake’s initial goal, however, was syntax checking
compiled languages like C by running a custom make target. The
flexibility needed to make all of this work makes configuring
flymake quite involved.

However, for syntax checking a scripting language, you usually copy
a recipe off the emacswiki and be done with it. There’s also a
recipe for ruby, but there was nothing to syntax check ERB
templates with embedded ruby code.

This is how an ERB template usually looks like:

<h1>My awesome blog!</h1>   <% @posts.each do |post| %> <div class="post"> <h2><%= post.title %></h2> <%= post.body %> </div> <% end %>

Configuring flymake consists of these steps:

1. Write a flymake init function that takes the contents of the
   current buffer, writes it to a temporary file, sets
   flymake-temp-source-file-name and returns a list with a program to
   call and the arguments to pass to it. This program should return
   with a non-zero exit code in case of errors or warnings.
2. Tell flymake to use this function for a certain type of file by
   adding an entry to flymake-allowed-file-name-masks.
3. You might need to add an entry to flymake-err-line-patterns
   with a regex that matches the output of your syntax checker.
4. Turn on flymake-mode.

For making flymake work with ERB the trick is to get the init
function right. Instead of just copying the buffer we have to
transform it from ERB to plain ruby. This can be done by calling
the erb command line utility with the -x switch. The lines in the
resulting ruby code correspond to their equivalents in the ERB
template which is crucial for flymake to highlight errors
correctly. Here the code:

(defun flymake-erb-init () (let* ((check-buffer (current-buffer)) (temp-file (flymake-create-temp-inplace (buffer-file-name) "flymake")) (local-file (file-relative-name temp-file (file-name-directory buffer-file-name)))) (save-excursion (save-restriction (widen) (with-temp-file temp-file (let ((temp-buffer (current-buffer))) (set-buffer check-buffer) (call-process-region (point-min) (point-max) "erb" nil temp-buffer nil "-x")))) (setq flymake-temp-source-file-name temp-file) (list "ruby" (list "-c" local-file)))))

You now need to tell flymake to use this function for files with an
extension of .erb:

(push '("\\.erb$" flymake-erb-init) flymake-allowed-file-name-masks)

If you’re still working with files that have a .rhtml extension you
can use this instead:

(push '("\\.\\(erb\\|rhtml\\)$" flymake-erb-init) flymake-allowed-file-name-masks)

Flymake doesn’t come with a pattern for ruby’s error messages, but
you might still have this line if you’re already got syntax
checking for plain ruby files set up:

(push '("^\\(.*\\):\\([0-9]+\\): \\(.*\\)$" 1 2 nil 3) flymake-err-line-patterns)

As you can only add to a list once the library defining it is
loaded you either have to (require 'flymake) first or wrap these
statements in an eval-after-load:

(eval-after-load "flymake" '(progn (push '("\\.\\(erb\\|rhtml\\)$" flymake-erb-init) flymake-allowed-file-name-masks) (push '("^\\(.*\\):\\([0-9]+\\): \\(.*\\)$" 1 2 nil 3) flymake-err-line-patterns)))

Finally you have to make sure flymake-mode is turned on for all .erb
files. If you’re using html-mode for your templates this might
work:

(add-hook 'html-mode-hook 'flymake-mode-on)

However, ERB templates can be used in different places: for
configuration files, YAML fixtures or maybe even CSS. And you might
also have static HTML pages that are not ERB templates and don’t
need to be checked. A possible way to turn on flymake-mode for all
files with an .erb extension would be to turn it on from the
find-file-hook like this:

(defun turn-on-flymake-for-erb-files () (when (string-match "\.\\(erb\\|rhtml\\)$" (buffer-file-name)) (flymake-mode-on))) (add-hook 'find-file-hook 'turn-on-flymake-for-erb-files)

Here’s the complete code for you to copy and paste:

(defun flymake-erb-init () (let* ((check-buffer (current-buffer)) (temp-file (flymake-create-temp-inplace (buffer-file-name) "flymake")) (local-file (file-relative-name temp-file (file-name-directory buffer-file-name)))) (save-excursion (save-restriction (widen) (with-temp-file temp-file (let ((temp-buffer (current-buffer))) (set-buffer check-buffer) (call-process-region (point-min) (point-max) "erb" nil temp-buffer nil "-x")))) (setq flymake-temp-source-file-name temp-file) (list "ruby" (list "-c" local-file)))))   (eval-after-load "flymake" '(progn (push '("\\.\\(erb\\|rhtml\\)$" flymake-erb-init) flymake-allowed-file-name-masks) (push '("^\\(.*\\):\\([0-9]+\\): \\(.*\\)$" 1 2 nil 3) flymake-err-line-patterns)))   (defun turn-on-flymake-for-erb-files () (when (string-match "\.\\(erb\\|rhtml\\)$" (buffer-file-name)) (flymake-mode-on))) (add-hook 'find-file-hook 'turn-on-flymake-for-erb-files)

Eine Weile ist es her, aber ich habe mal wieder etwas zu berichten und zu dokumentieren. Mein Terminal des Herzens unter Linux ist rxvt-unicode, oder auch kurz urxvt. Zusaetzlich bin ich sehr begeistert ueber die Farben vom Projekt Tango. Wie passend, dass urxvt per Konfiguration einem die Moeglichkeit gibt die Standardfarben anzupassen. Also habe ich mir [...]