<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Blogs on ./lt</title>
    <link>https://www.ltaake.com/blog/</link>
    <description>Recent content in Blogs on ./lt</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Sun, 27 Nov 2022 03:14:08 +0200</lastBuildDate><atom:link href="https://www.ltaake.com/blog/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Should I Document This?</title>
      <link>https://www.ltaake.com/blog/2022/11/should-i-document-this/</link>
      <pubDate>Sun, 27 Nov 2022 03:14:08 +0200</pubDate>
      
      <guid>https://www.ltaake.com/blog/2022/11/should-i-document-this/</guid>
      <description>If you consider how software documentation is usually created in everyday life, you can certainly understand why some developers keep it rather thin. (It should be mentioned that I&amp;rsquo;m talking about an agile development process in the broadest sense - extensive up-front documentation, dictated from the ivory tower and written down in stone tablets would not be something I would want to write about here). So now, as an agile developer, when I&amp;rsquo;ve built a new feature or done a major refactoring, I ask myself the question, &amp;ldquo;Should I document this change?</description>
    </item>
    
    <item>
      <title>A Naive Case of UX-Design</title>
      <link>https://www.ltaake.com/blog/2022/07/a-naive-case-of-ux-design/</link>
      <pubDate>Wed, 20 Jul 2022 03:14:08 +0200</pubDate>
      
      <guid>https://www.ltaake.com/blog/2022/07/a-naive-case-of-ux-design/</guid>
      <description>Some time ago, due to a lack of a mobile flat rate, I started to not only pay for the landline connection included in my DSL line, but actually use it as such. Because it was a VoIP connection and I didn&amp;rsquo;t have any suitable hardware at hand, I decided on a software solution in the form of a Raspberry Pi with an Asterisk server and an app to use my smartphone as a telephone.</description>
    </item>
    
    <item>
      <title>Applied Functional Refactoring in Java</title>
      <link>https://www.ltaake.com/blog/2017/11/applied-functional-refactoring-in-java/</link>
      <pubDate>Fri, 17 Nov 2017 03:14:08 +0200</pubDate>
      
      <guid>https://www.ltaake.com/blog/2017/11/applied-functional-refactoring-in-java/</guid>
      <description>Just a little bit of context upfront: the project on which I did the refactoring was Spring Boot based and about two years old. It did already use some functional elements, for example the new streaming-API. More advanced features were just sparely used, so there was a lot of space for introducing more functional elements.
Repeated conditional operations For most projects that have domain entities with a large number of fields, there might be some mapping, state checking, or similar operation that involves evaluating structurally identical conditions for each field and executing some functionality, e.</description>
    </item>
    
    <item>
      <title>Static code-analysis for Domain Driven Design, Part 1</title>
      <link>https://www.ltaake.com/blog/2017/09/static-code-analysis-for-domain-driven-design-part-1/</link>
      <pubDate>Fri, 29 Sep 2017 13:45:08 +0200</pubDate>
      
      <guid>https://www.ltaake.com/blog/2017/09/static-code-analysis-for-domain-driven-design-part-1/</guid>
      <description>Of course, doing a static code-analysis can&amp;rsquo;t in any way tell you that you are doing DDD correctly. But what it can do, is to help you to meet some basic principles like a clean aggregate structure and keep them intact over time. The implementation details of Domain Driven Design that I have taken a look on for my analysis are mostly based on common literature, in particular &amp;ldquo;Domain-driven Design&amp;rdquo; by Eric Evans and &amp;ldquo;Implementing Domain-driven Design&amp;rdquo; by Vaughn Vernon.</description>
    </item>
    
    <item>
      <title>Introducing an advanced LaTeX toolchain</title>
      <link>https://www.ltaake.com/blog/2017/09/introducing-an-advanced-latex-toolchain/</link>
      <pubDate>Fri, 15 Sep 2017 20:51:00 +0200</pubDate>
      
      <guid>https://www.ltaake.com/blog/2017/09/introducing-an-advanced-latex-toolchain/</guid>
      <description>At some point most, if not all, developers have to write some kind of large text document, be it documentation or a bachelor, master or other thesis. As you&amp;rsquo;re just reading this right now, I suspect you might be just starting to write one yourself. Choosing the toolchain for such a document wisely makes enormous differences. That is especially important if you&amp;rsquo;re working on a document with multiple people. I learned this the hard way, while writing a 40 page documentation with 6 people using different versions of Word running on different operating systems.</description>
    </item>
    
  </channel>
</rss>
