atom.xml

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">

  <title><![CDATA[Albrechts Blog]]></title>
  <link href="http://aschei.github.io/atom.xml" rel="self"/>
  <link href="http://aschei.github.io/"/>
  <updated>2017-04-21T00:11:35+02:00</updated>
  <id>http://aschei.github.io/</id>
  <author>
    <name><![CDATA[Albrecht Scheidig]]></name>
    
  </author>
  <generator uri="http://octopress.org/">Octopress</generator>

  
  <entry>
    <title type="html"><![CDATA[Services in Ubuntu 16.04]]></title>
    <link href="http://aschei.github.io/blog/2017/04/20/services-in-ubuntu-16-dot-04/"/>
    <updated>2017-04-20T23:37:09+02:00</updated>
    <id>http://aschei.github.io/blog/2017/04/20/services-in-ubuntu-16-dot-04</id>
    <content type="html"><![CDATA[<p>Ubuntu since 14.04 switches to <a href="https://freedesktop.org/wiki/Software/systemd/">systemd</a> to manage services. Time to
learn something new.</p>

<p>Key to systemd is the command <code>systemctl</code></p>

<p>Disable a service (so that it does not start when system reboots):<br>
<code>sudo systemctl disable mongodb</code></p>

<p>Enable a service (for automatic startup when system reboots):<br>
<code>sudo systemctl enable mongodb</code></p>

<p>Start / Stop a service:<br>
<code>sudo systemctl start mongodb</code><br>
<code>sudo systemctl stop mongodb</code><br></p>

<p>Further helpful tweaks for systemd on <a href="https://wiki.ubuntuusers.de/systemd/Service_Units/">this page</a>.
See also <a href="http://aschei.github.io/blog/2013/12/16/howto-disable-daemons-permanently/">this</a> former post about upstart and systemv runlevels.</p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[Radieschensalat]]></title>
    <link href="http://aschei.github.io/blog/2015/07/05/radieschensalat/"/>
    <updated>2015-07-05T13:00:20+02:00</updated>
    <id>http://aschei.github.io/blog/2015/07/05/radieschensalat</id>
    <content type="html"><![CDATA[<h2>Ein leckerer Sommersalat als Beilage oder zwischendurch</h2>

<p>Wohin mit den Radieschen? Dieser Salat ist eine leckere Option, wenn man ein paar Radieschen übrig hat.
Und die Zubereitung ist denkbar einfach.</p>

<h2>Zutaten für zwei Personen</h2>

<ol>
<li>Ein Bund <strong>Radieschen</strong></li>
<li>Eine gute Handvoll <strong>Petersilie</strong></li>
<li>Geschmacksneutrales Öl, z.B. Rapsöl</li>
<li>Essig, z.B. Balsamico</li>
<li>Salz</li>
</ol>


<h2>Zubereitung</h2>

<ol>
<li>Radieschen waschen und kleinschneiden.</li>
<li>Petersilie waschen und fein wiegen.</li>
<li>Radieschen und Petersilie in einer Schüssel vermengen.</li>
<li>2 EL Öl dazu.</li>
<li>1-2 TL Essig dazu.</li>
<li>Gut salzen und vermengen.</li>
</ol>


<p>Neben dem beliebten Balsamico können auch gerne andere Essige verwendet werden, z.B. Weinessig.</p>

<p>Petersilie, Öl und Salz nehmen den Radieschen die Schärfe, das Essig setzt einen geschmachlichen
Kontrapunkt, darf aber nicht dominieren &ndash; daher vorsichtig dosieren.</p>

<p>Der Salat darf gerne eine Stunde durchziehen, muss aber nicht.</p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[Determining affected tests using coverage info]]></title>
    <link href="http://aschei.github.io/blog/2015/05/01/determining-affected-tests-using-coverage-info/"/>
    <updated>2015-05-01T00:36:32+02:00</updated>
    <id>http://aschei.github.io/blog/2015/05/01/determining-affected-tests-using-coverage-info</id>
    <content type="html"><![CDATA[<p>If have got an idea inspired by <a href="http://tenderlovemaking.com/2015/02/13/predicting-test-failues.html">this post</a>.</p>

<p>Every time when me or a build server runs a complete build on a commit with all tests, it could store
detailed coverage information and associate it with this commit.</p>

<p>Later on, when for instance I am fixing a bug, it should be possible to git diff the working directory to the latest
parent commit that has associated coverage info. Looking up the changes and the coverage info, one could tell what
tests are likely to be affected by the changes in between.</p>

<p>If I then run only those tests, I am pretty confident that other tests will not break by my changes. I am not 100% sure
but I am confident enough to commit the stuff and let the build server run a complete build which leads to new
coverage info associated with this new commit.</p>

<p>Some requirements I have in mind:</p>

<ul>
<li>Should work as a maven goal &ldquo;mvn affected:test&rdquo;</li>
<li>Should work with git to provide diff and coverage info association.</li>
<li>Should work with remotely stored coverage info. (Is it possible to store custom information associated with a commit into git repository?)</li>
<li>Should work with <a href="http://mojo.codehaus.org/cobertura-maven-plugin/dump-datafile-mojo.html">cobertura</a></li>
</ul>


<p>I would really like to know, if I am the only one that thinks such a maven plugin would be useful,
what obstacles you see, if there are better alternatives to cobertura and git or if a broader approach would make more sense.
Let me know.</p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[Tool dilemma]]></title>
    <link href="http://aschei.github.io/blog/2015/02/22/tool-dilemma/"/>
    <updated>2015-02-22T21:49:29+01:00</updated>
    <id>http://aschei.github.io/blog/2015/02/22/tool-dilemma</id>
    <content type="html"><![CDATA[<p>If you write enterprise-size software in Java, you ran sooner or later into
a dilemma regarding tools.</p>

<p>On one hand you know that using IDEs like Eclipse drives efficiency and adds
support for streamlined workflows. IDEs provide handy features like call
hierarchy and integrated debugging.</p>

<p>On the other hand IDEs tend to introduce questionable artefacts into the
overall build infrastructure, and sometimes lead decisions for questions
regarding architecture.</p>

<p>If you e.g. use maven as your dependency and build infrastructure then those
IDEs have to completely understand your maven declarations to know about the
classpath, output folders, compiler level etc. You tend to avoid maven features
that your favorite IDE does not understand.</p>

<p>If you always follow standard solutions and best practises, there might be no
big issue between IDE and maven build. But sooner or later there will appear
challenges for the IDE such as cross compiling, multi-projects, generated code.</p>

<p>In such situations it is recommended to take a step back and analyze the
overall requirements for architecture and build infrastructure.
Why do we have this generated code, where is it used, what does the generation
depend on, when should it executed?
As a result, you should have created a reasonable model of all build steps and
an acyclic module dependency model.
Often the root of all evil lies in unmanaged architecture and build
infrastructure. Fix this and go ahead.</p>

<p>Step number two should reflect the findings from step one into the actual
dependency declarations and build infrastructure. A valid result of this
step is a working command line build.</p>

<p>And then it is the last step that the IDE is tweaked to support the desired
architecture. Sometimes, during this step, build infrastructure needs to be
extended or even changed a little bit, but never should the changes go so far
as to change the desired architecture. If the IDE is not able to cover the
target architecture then you should propable rethink if this IDE is a good
choice or if your requirements are too ambitious.</p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[Bye bye, cygwin]]></title>
    <link href="http://aschei.github.io/blog/2014/12/02/bye-bye-cygwin/"/>
    <updated>2014-12-02T22:51:28+01:00</updated>
    <id>http://aschei.github.io/blog/2014/12/02/bye-bye-cygwin</id>
    <content type="html"><![CDATA[<p>At work, we use windows computers, and I am currently in the transition from one computer to the next one.
This process typically takes at least a month, until I am confident enough that I have not missed something.</p>

<p>Today, I realized that I will not install cygwin on the new computer, because&hellip; <em>Well, I have not used it for ages</em>.
During the last years, I&rsquo;ve always run at least one Virtual Machine with Ubuntu on my Windows host, that gives me a
fully fledged Linux environment with access to the file system of the host.</p>

<p>Before that time I used to reinstall cygwin and transferred settings and scripts until everything worked again.</p>

<p>But today I have no real use case to do so. The pain in a mixed environment (file name encoding, line endings, etc.)
is the same for both techniques. I also have no use for DOS scripts using Unix tools compiled for DOS.</p>

<p>So all in all I would like to say Good Bye to cygwin and thanks for all the fish.</p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[A replacement for Truecrypt]]></title>
    <link href="http://aschei.github.io/blog/2014/06/16/a-replacement-for-truecrypt/"/>
    <updated>2014-06-16T01:08:00+02:00</updated>
    <id>http://aschei.github.io/blog/2014/06/16/a-replacement-for-truecrypt</id>
    <content type="html"><![CDATA[<p>When I realized that Truecrypt will no longer be developed I looked around for a proper replacement.</p>

<p>In the end I wrote a set of scripts to ease the mounting of AES encrypted file containers under Linux. Let&rsquo;s say this is a command line truecrypt replacement.</p>

<p>Check it out <a href="https://github.com/aschei/encdrive">here</a>.</p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[How to disable daemons under Ubuntu 12.04 and above]]></title>
    <link href="http://aschei.github.io/blog/2013/12/16/howto-disable-daemons-permanently/"/>
    <updated>2013-12-16T22:35:00+01:00</updated>
    <id>http://aschei.github.io/blog/2013/12/16/howto-disable-daemons-permanently</id>
    <content type="html"><![CDATA[<p>Ubuntu uses the <a href="http://upstart.ubuntu.com/">upstart</a> system to start several services. Every service controlled via upstart has a .conf file in the directory /etc/init, so you can list the available services using
<code>
ls -l /etc/init/*.conf
</code></p>

<p>To disable a service, upstart supports a <a href="http://upstart.ubuntu.com/cookbook/#manual">&ldquo;manual&rdquo;</a> configuration element, that can be placed either in the &lt;service>.conf file or in an overriding file &lt;service>.override using
<code>
sudo sh -c &ldquo;echo &lsquo;manual&rsquo; > /etc/init/SERVICE.override&rdquo;
</code></p>

<p>To reenable the service just delete the .override file.</p>

<p>Not every service is controlled via upstart, on my system e.g. nessus is controlled via init.d. Services controlled via init.d are configured using an executable script in /etc/init.d and links to this script, that are located in /etc/rc?.d, according to the certain runlevels. To disable such a service, the easiest option is to remove the executable flag from the script, such as</p>

<p><code>
sudo chmod -x /etc/init.d/nessusd
</code></p>

<p>To revert your decision, just add the executable bit again:</p>

<p><code>
sudo chmod +x /etc/init.d/nessusd
</code></p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[Blog on GitHub using Octopress]]></title>
    <link href="http://aschei.github.io/blog/2013/08/01/blog-on-github-using-octopress/"/>
    <updated>2013-08-01T01:54:00+02:00</updated>
    <id>http://aschei.github.io/blog/2013/08/01/blog-on-github-using-octopress</id>
    <content type="html"><![CDATA[<p>Today, I have stumbled upon a blog that uses <a href="http://octopress.org">Octopress</a>. It looked very clean, and I read something about Octopress and it&rsquo;s concepts.</p>

<p>It seemed similar to my current blog setup, meaning that it produces static pages out of the sources, that can then be transferred to the web server and be served very fast and easily.</p>

<p>Octopress also offers easy integration with <a href="http://pages.github.com/">Github Pages</a>. Github Pages is a hosting service of Github that is coupled to a GIT repository on GitHub. Just push changes to the GIT repository, and within seconds the changes are reflected on the respective site.</p>

<p>My repository is located <a href="https://github.com/aschei/aschei.github.io">here</a>, and the site can be viewed <a href="http://aschei.github.io">here</a>.</p>

<p>A cool concept octopress makes use of is to keep sources and the generated results in the same repository by using branches. Sources are committed to branch <a href="https://github.com/aschei/aschei.github.io/tree/source">&ldquo;source&rdquo;</a>, while the result is committed to <a href="https://github.com/aschei/aschei.github.io/tree/master">&ldquo;master</a>. The two branches contain conceptually completely different artifacts, and they will never get merged.</p>

<p>The whole setup is really easy to make and it is a joy to work with it.</p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[How my other site was built]]></title>
    <link href="http://aschei.github.io/blog/2013/05/09/howsitewasbuilt/"/>
    <updated>2013-05-09T17:52:00+02:00</updated>
    <id>http://aschei.github.io/blog/2013/05/09/howsitewasbuilt</id>
    <content type="html"><![CDATA[<p>When planning my other blogging <a href="http://aschei.x64.me">site</a> I have had some ideas what I want to achieve. I wanted a typical
blog site but with extra flexibility for trying out other stuff and learning about
different tools I am interested in.</p>

<p>I have had a special setup in mind: hosted on my own web server, no dynamic / interpreted
content on the server side, just static pages. For sure the pages need to be generated by
a flexible enough mini CMS.</p>

<p>So instead of going on with blogger.com I wanted to control my own web server and
build it from ground up. But I also had a very limiting requirement: no cost. Yes, I want
to try out stuff without paying anything more for it.</p>

<p>So the first thing to decide was about the web server. Luckily, Amazon currently offers
a year of free testing their hosting services. I setup a server on <a href="http://aws.amazon.com">AWS</a>
with the latest Debian and read about the service details that are included in Amazons free offer.
Two things to keep in mind: First, you have absolutely no guarantee on backups being made nor
failsafety etc. So it is vital to have your setup elsewhere in case your server is being
reset to factory defaults. I chose to prepare everything on my laptop and rsync stuff in case
of changes. More on that later. Second, you have one fix IP address (they call it Elastic IP)
to be bound on your instances. In case you would like to have a meaningful web server name
using a dynamic DNS hoster, you can register the Elastic IP there and give it a go. But a more
flexible approach is to register your IP automatically when your interface is up using a script
in /etc/network/if-up.d like so:
$$code(lang=bash, style=monokai)</p>

<pre><code>PubIP=$(curl http://169.254.169.254/latest/meta-data/public-ipv4)
curl --user ${USER}:${PASSWD} https://www.dnsdynamic.org/api/?hostname=${HOST}&amp;myip=${PubIP}
</code></pre>

<p>$$/code
Note: This works if you define USER, PASSWD and HOST before.</p>

<p>The result of this setup was an always-on server reachable in the internet using a meaningful name.
Next step was to decide which http server to use. I wanted a minimalistic setup, but
after reading a while here and there I learned that there are no good alternatives to Apache or
Nginx. Since I am experienced with Apache I went with <a href="http://nginx.org">Nginx</a> to learn something
new. Well, Nginx seems to be a bit easier to setup, but in the end it is just working like Apache.</p>

<p>OK, server is running, what about the CMS? After researching a while I went with
<a href="http://www.blogofile.com/">Blogofile</a> which calls itself a &ldquo;static website compiler&rdquo;. That was
exactly what I was looking for and I installed it on my laptop.</p>

<p>Blogofile gives you for each site a basic setup including features like Blogs etc. It is Python
based (but it can be used without Python knowledge).
It uses <a href="http://www.makotemplates.org/">Mako Templates</a> as a template engine which makes it easy
to change layout and reorganize stuff. For blog posts it supports markdown which I find handy to use.</p>

<p>As a result, whenever I would like to add a blog post I have to add a markdown file in the posts directory
and redeploy the site. For redeployment I am using the following script:
$$code(lang=bash, style=monokai)</p>

<pre><code>blogofile build -s ${site}
rsync -avz -e ssh ${site}/_site/ ${sshhost}:/var/www/
</code></pre>

<p>$$/code
Works like a charm.</p>

<p>If ever the AWS server dies, I would have to reinstall and configure Nginx and the dyndns script,
done. If ever my laptop dies, I would be screwed. Setting up programs like Blogofile is no fun but
possible, but the valuable content would be lost. Therefore I commit my stuff to
<a href="http://github.com">Github</a>.</p>

<p>For me, this is a fun project. I have learned about EC2 on amazon, setting up and securing Debian,
writing shell scripts, Nginx, Blogofile, a little bit Python, and Git on Github. And it gives enough
room to play around.</p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[Avoid big bug backlogs]]></title>
    <link href="http://aschei.github.io/blog/2013/04/18/bug-backlog/"/>
    <updated>2013-04-18T21:24:00+02:00</updated>
    <id>http://aschei.github.io/blog/2013/04/18/bug-backlog</id>
    <content type="html"><![CDATA[<p>I strongly recommend to avoid long lists of bugs. Today, we have cool tools like <a href="http://bugzilla.org">Bugzilla</a>
or <a href="http://www.atlassian.com/software/jira/">Jira</a> that make tracking bugs real fun even if there are big numbers of it.</p>

<p>I can imagine a situation where a software product has no known bugs and is complete in a functional sense.
However, I have never been in this situation since I have started working on software. The typical situation I experience is:</p>

<ul>
<li><p>you have got plenty of things that should be improved, extended, added &ndash; more than you can implement.</p></li>
<li><p>you have got plenty of bug tickets, more than you can handle.</p></li>
</ul>


<p>If you are in a situation where you sell software you are developing you also have to
weigh effort, priorities, expected damage caused by bugs and expected gain from improvements. You cannot
implement what you want. So how about filling lists of features, lists of bugs, prioritize them, estimate
them roughly, and finally decide what is the next important item that should be implemented? It sounds
promising. You only have to manage one list that is sorted by a function depending on effort, estimate,
priority etc. and sort new items into this list.</p>

<p>Feed the first four items of this ultimate list to a <a href="http://en.wikipedia.org/wiki/Kanban_board">Kanban-Board</a>
every day and let the developers pick items in order.</p>

<p>Bullshit.</p>

<p>In my experience you cannot prioritize bugs and features into one list. You simply cannot compare
them. Maybe a prioritized backlog is good for features, but it is not for bugs. Bugs are not a thing
of planning or betting on. Bugs are the bill you get for your past work. You simply cannot avoid to pay that bill.</p>

<p>I recommend the following to process bugs:</p>

<ul>
<li><p>If a bug comes in: Decide if it is really a bug or possibly an enhancement (enhancement &ndash;> feature backlog).</p></li>
<li><p>Decide if you want to fix the bug. The decision should only take into account the level of quality
you want to deliver, not what other things you have on your agenda.</p></li>
<li><p>If the bug is not important enough &ndash; and this is the important point &ndash; <em>close it as &ldquo;won&rsquo;t fix&rdquo;</em>.</p></li>
<li><p>Otherwise choose between three severities: Fix it &ldquo;now&rdquo;, &ldquo;today or tomorrow&rdquo;, &ldquo;within the next two weeks&rdquo;.</p></li>
<li><p>Assign the bug to a person that should fix it actually.</p></li>
<li><p>Measure time spent on bug fixing. If it goes beyond 15 percent take a sharp look what is happening with
your software.</p></li>
</ul>


<p>So why not simply give non important bugs a low priority and keep them in the list? Why not say: &ldquo;Hey,
if one has nothing to do: just pick a bug from the &#8220;non-important&rdquo; pool.&ldquo; For me this would be a statement
like &#8220;We provide a quality level that depends on the time that is left over&rdquo;.
It is also unclear if this sort of bugs should be part of a &ldquo;open bugs&rdquo; statistic. More: In the
unlikely case that someone would have time left over: What bug would she select? How would she choose from
the list of 100k bugs?
So just close these bugs and enjoy the pleasures of the real, lean bug list.</p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[Development principles I am convinced of]]></title>
    <link href="http://aschei.github.io/blog/2013/04/13/principles/"/>
    <updated>2013-04-13T02:21:00+02:00</updated>
    <id>http://aschei.github.io/blog/2013/04/13/principles</id>
    <content type="html"><![CDATA[<p>In my current company we had tried out several agile processes including Kanban and Scrum,
but in some areas we have decided to go back to &ldquo;old school&rdquo; practises. We have four week iterations,
continous integration, automated build systems etc. But on the other hand we &ldquo;push&rdquo; tasks to
developers, have code ownership, do very little pair programming and skip to write unit tests in non
trivial areas like UI. We are successful with this process, but it depends how you measure success.</p>

<p>There are some things I do not like:</p>

<ul>
<li><p>Big back logs, including lot&rsquo;s of prio 4 or 5 bugs you keep to fix them later if you have the time.</p></li>
<li><p>Big stocks of unfinished work, like features in branches that cannot be merged because of x, y, z.</p></li>
<li><p>Requirements on estimations that go beyond a gut feeling. Especially I hate a) to &ldquo;break down&rdquo;
a piece of work, estimate the parts and sum it up, and b) handle estimations like promises.</p></li>
<li><p>Making detailed plans that go beyond the next week. I have no problems with making plans
that define a complete year, but the granularity should be appropriate.</p></li>
</ul>


<p>And, there are some practises I am convinced of:</p>

<ul>
<li><p>Stick to quality. If a bug appears: fix it or kill it if it is not worth it. If you see stuff to clean up: clean it up.</p></li>
<li><p>Spend time on infrastructure to automate stuff, spend time on improving performance of your
build process. Use command line scripts to automate stupid, repetitive work.</p></li>
<li><p>Write unit tests that really test a unit of work, i.e. a class. Write unit tests. Do not mistake
integration tests for unit tests.</p></li>
<li><p>Don&rsquo;t trust process evangelists, every group of people working together in a project needs a
different process to get the best ressults out. And that process needs to be refactored like your code.</p></li>
</ul>

]]></content>
  </entry>
  
</feed>