This is a valid RSS feed.
This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.
<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>Stefan Tilkov’s Blog</title>
<link>https://www.innoq.com/blog/st/index.xml</link>
<description>Recent content on Stefan Tilkov’s Blog</description>
<generator>Hugo -- gohugo.io</generator>
<language>en-us</language>
<lastBuildDate>Sun, 22 Jan 2017 23:00:00 +0100</lastBuildDate>
<atom:link href="https://www.innoq.com/blog/st/index.xml" rel="self" type="application/rss+xml" />
<item>
<title>Software Engineering Radio Update</title>
<link>https://www.innoq.com/blog/st/2017/01/software-engineering-radio-update/</link>
<pubDate>Sun, 22 Jan 2017 23:00:00 +0100</pubDate>
<guid>https://www.innoq.com/blog/st/2017/01/software-engineering-radio-update/</guid>
<description><p>Good news: SE Radio <a href="http://www.se-radio.net/2017/01/were-listening/">has decided to stop the ad</a> I was offended by, and
will even remove it from past episodes. I think that is pretty great
for the show’s listeners and for the show itself.</p>
<p>As for me, I won’t return to the show. We’re parting on good terms, no
hard feelings on either side. On the contrary: I encourage you to
listen to the show – I know I will continue to do so, it’s pretty
great.</p>
<p>Nevertheless, I’ll be taking the chance to start a new podcast,
together with a few of my former show hosts and some esteemed
co-workers. Preparations are progressing smoothly, and I expect I’ll
be able to announce something over the next few days.</p>
</description>
</item>
<item>
<title>No More End-to-End-Cyber: Why I've Resigned from Software Engineering Radio</title>
<link>https://www.innoq.com/blog/st/2017/01/no-more-end-to-end-cyber-why-ive-resigned-from-software-engineering-radio/</link>
<pubDate>Sat, 14 Jan 2017 18:00:00 +0100</pubDate>
<guid>https://www.innoq.com/blog/st/2017/01/no-more-end-to-end-cyber-why-ive-resigned-from-software-engineering-radio/</guid>
<description><p>I&rsquo;ve just announced my resignation from <a href="http://www.se-radio.net">Software Engineering Radio</a>, a podcast I&rsquo;ve been involved with for quite some time.</p>
<p>The TL;DR of the explanation: I refuse to have ads from US arms manufacturers placed into a podcast against my will.</p>
<p>I first appeared as a guest on SE Radio talking about REST
<a href="http://www.se-radio.net/2008/05/episode-98-stefan-tilkov-on-rest/">a very long time ago</a>,
interviewed by <a href="http://www.voelter.de">Markus Völter</a>, the podcast’s
founder. I joined again as a guest
<a href="http://www.se-radio.net/2014/09/episode-210-stefan-tilkov-on-architecture-and-micro-services/">talking about monoliths and microservices</a>,
before becoming one of the hosts. I recorded a number of episodes with
an amazingly great set of guests, including
<a href="http://www.se-radio.net/2016/07/se-radio-episode-263-camille-fournier-on-real-world-distributed-systems/">Camille Fournier</a>,
<a href="http://www.se-radio.net/2016/06/se-radio-episode-261-david-heinemeier-hansson-on-the-state-of-rails-monoliths-and-more/">David Heinemeier Hansson</a>,
<a href="http://www.se-radio.net/2016/05/se-radio-episode-257-michael-nygard-on-clojure-in-practice/">Michael Nygard</a>,
<a href="http://www.se-radio.net/2016/05/se-radio-episode-256-jay-fields-on-working-effectively-with-unit-tests/">Jay Fields</a>,
<a href="http://www.se-radio.net/2016/02/se-radio-episode-249-vaughn-vernon-on-reactive-programming-with-the-actor-model/">Vaughn Vernon</a>,
<a href="http://www.se-radio.net/2015/11/se-radio-episode-241-kyle-kingsbury-on-consensus-in-distributed-systems/">Kyle Kingsbury</a>,
<a href="http://www.se-radio.net/2015/07/episode-232-mark-nottingham-on-http2/">Mark Nottingham</a>,
and
<a href="http://www.se-radio.net/2014/12/episode-216-adrian-cockcroft-on-the-modern-cloud-based-platform/">Adrian Cockcroft</a>. I
enjoyed the chance to spend time talking to my guests tremendously,
and I’m pretty sure quite a few listeners enjoyed the results, too.</p>
<p>For a long time, SE Radio has been run by the IEEE Computer Society, the organization Markus Völter handed the podcast over to when he resigned from it. This has had positive effects, such as taking on <a href="http://www.se-radio.net/team/robert-blumen/">Robert Blumen</a> as an editor, who does a great job maintaining the herd of cats that is the show host team.</p>
<p>The decision to run ads was discussed with the podcast hosts, and while I prefer podcasts that don’t have ads, I understand that they’re a great way to offset the cost and potentially even make some money. But the first ad to appear in the SE Radio podcast was one by <a href="https://en.wikipedia.org/wiki/Northrop_Grumman">Northrop Grumman</a>, and it was not only one that I found very questionable from an ethics standpoint, but also intolerably stupid (“your leader in end-to-end cyber”, you’ve got to be kidding me).</p>
<p>I might have tolerated this, but the straw that broke the camel’s back
were some discussions about editorial policies regarding politics and
ethics discussions in the podcasts itself. This, in combination with
running an ad for technology for today’s battlefield (which, you know,
“is increasingly cyber”), was just too much.</p>
<p>Sadly, SE Radio is now part of the IEEE Computer Society, an
organization with strong ties to the US military and its vendors, and
my and some other hosts’ attempts to do anything about this led to no
resolution. The IEEE CS is free to not care about the views of its
hosts. I’m free to spend my free time somewhere else.</p>
<p>Which is actually something I’m currently actively planning on doing;
stay tuned for some podcast-related news sometime soon.</p>
</description>
</item>
<item>
<title>Don’t start with a monolith</title>
<link>https://www.innoq.com/blog/st/2015/06/dont-start-with-a-monolith/</link>
<pubDate>Mon, 08 Jun 2015 12:12:00 +0100</pubDate>
<guid>https://www.innoq.com/blog/st/2015/06/dont-start-with-a-monolith/</guid>
<description><p>I’ve been an avid follower of Martin Fowler’s work ever since I read
<a href="https://books.google.de/books/about/Analysis_Patterns.html?id=4V8pZmpwmBYC&amp;redir_esc=y">“Analysis Patterns”</a> almost 20 years ago. I’ve always appreciated the
way he manages to distill complex topics down to their essence, and I
think the immense number of people reading <a href="http://martinfowler.com">martinfowler.com</a> is well
deserved. I’m also lucky to have met Martin in person numerous times and was
thus able to discuss many of the topics we share an interest in with
him.</p>
<p>Therefore I couldn’t be more pleased to have been able to publish
<a href="http://martinfowler.com/articles/dont-start-monolith.html">my rebuttal</a> to <a href="http://martinfowler.com/bliki/MonolithFirst.html">his latest piece</a> on Microservices over on his website.</p>
</description>
</item>
<item>
<title>Thoughts on a Canonical Data Model</title>
<link>https://www.innoq.com/blog/st/2015/03/thoughts-on-a-canonical-data-model/</link>
<pubDate>Mon, 30 Mar 2015 12:12:00 +0100</pubDate>
<guid>https://www.innoq.com/blog/st/2015/03/thoughts-on-a-canonical-data-model/</guid>
<description><p>Over on the innoQ company blog, I&rsquo;ve published a post on why I believe a canonical data model is a bad idea. <a href="https://www.innoq.com/en/blog/thoughts-on-a-canonical-data-model/">Enjoy</a>.</p>
</description>
</item>
<item>
<title>Wenn AngularJS eine schlechte Idee ist</title>
<link>https://www.innoq.com/blog/st/2014/12/wenn-angularjs-eine-schlechte-idee-ist/</link>
<pubDate>Thu, 04 Dec 2014 11:23:00 +0100</pubDate>
<guid>https://www.innoq.com/blog/st/2014/12/wenn-angularjs-eine-schlechte-idee-ist/</guid>
<description><p><em>Mein Kollege Sebastian Janzen, seines Zeichens bekennender
AngularJS-Fan, hat den folgenden Text in seinem internen Blog
gepostet – und ich konnte es mir nicht verkneifen, ihn zu fragen, ob
ich ihn als Gast-Post hier veröffentlichen darf. Hier also seine
(weisen) Worte …</em></p>
<p>Ich habe nun mehrmals zwei Phänomene beobachtet: Ein Entscheider - je
größer die Firma desto eher zutreffend - hat keine Lust mehr, in die
gelangweilten, von Prozess-Narben geprägten Gesichter seiner
Entwickler zu schauen. Er möchte das Team positiv überraschen und überträgt
für das nächste Projekt AngularJS von einer Buzzword- in die
Requirements-Liste, denn Entwickler möchten endlich mal was Cooles
machen. In einem Meeting für eine neue Webseite packt er stolz den
heiligen SPA-Gral AngularJS aus. Alle Probleme sind gelöst, die
Entwickler sind happy, das kommt in die Requirements.</p>
<p>Und nun wird noch jemand von innoQ dazu geholt und hinterfragt
kritisch das Entwickler-Glück. &ldquo;AngularJS? Sie wissen schon, dass dies
an der Stelle nicht so ganz zu Ihrem Problem passt?&rdquo;</p>
<p>So sehr ich Angular mag und es im ein oder anderen Bereich für richtig
halte eine SPA zu bauen, so fatal kann es auch laufen, wenn man damit
versucht Probleme zu erschlagen, die gegensätzlicher nicht sein
könnten. Beispiele:</p>
<ul>
<li><p><em>Meine Anwendung soll rasend schnell sein!</em> <br/> Ja, das kann sie als SPA
sein, jedoch nicht, wenn man zwischen dieser und anderen Seiten
ständig hin und her wechselt. Ein OpenID-Provider liefert in der Regel
zwei Seiten aus: Login und Success + Redirect. Die Aufenthaltsdauer
muss eine SPA rechtfertigen! Und für den Besucher ist es egal, ob es
eine technisch perfekte Seite ist. Das wird seine Aufenthaltszeit
nicht verlängern, sondern verkürzen.</p></li>
<li><p><em>Die coolen Seitenübergänge gehen nur in Angular!</em> <br/> Nein, die sind
mit CSS erzeugt oder im Fallback mit jQuery.animate. Genau dieser
Technik bedient sich Angular auch, denn es ist in JavaScript
geschrieben - nicht mehr und nicht weniger. Es hat weder Zugriff auf
Hardware, noch kann es den IE 8 zu einem coolen Browser machen.</p></li>
<li><p><em>Bei Angular muss ich mich nicht mehr um den DOM kümmern</em> <br/> Uiuiui,
als ich das mal gehört habe hat sich bei mir alles rumgedreht. Ich
glaube ich habe in meiner Angular-Zeit noch nie so viel über die
Verzahnung zwischen DOM und JS gelernt - einfach aus der Not heraus,
Bugs zu finden. Manch einer erschlägt diese Bugs mit genügend
Timeouts. Und viele Plugin-Entwickler machen das auch so, aber das ist
ziemlich weit weg von geil. Und vom eigentlichen
Performance-Ziel. Grundkonzepte wie Asynchronität in einem Browser
müssen verstanden werden, nicht hintergangen! Aus meiner Sicht geht
Angular mit diesem Umstand hervorragend um, es muss nur genutzt
werden.</p></li>
<li><p><em>Wir haben viel Angular-Erfahrung im Team</em> <br/> Sicher? Unterhaltet Euch
vorher mit dem Team, stellt Fragen, was die do&rsquo;s und don&rsquo;ts sind. Wenn
da nichts kommt oder die Frage &ldquo;Wofür setzt man Angular nicht ein?&rdquo;
unbeantwortet bleibt, dann haben diese Menschen nicht viel damit
gemacht. Da ist eine Lernphase von teilweise mehreren Wochen
einzuplanen und viel Debugging-Zeit. Eine schöne Frage ist auch &ldquo;Was
sind Promises?&rdquo;</p></li>
<li><p><em>Dieses Angular ist nur Frontend, dafür plane ich als Senior
Consultant mal zwei Stunden ein</em> <br/> Das wird scheitern. Angular ist ein
Framework, mit dem man tatsächlich eine Frontend-Architektur, die
diesem Namen auch gerecht wird, aufsetzen und planen kann. Es gibt
mehr als nur Data-Binding und Routen!</p></li>
</ul>
<p>Performante SPAs, die in allen modernen Browsern und im IE &gt;= 8 laufen
sind das Werk von Menschen, die sich durch und durch mit der Materie
beschäftigt haben und sehr viel Arbeit dort hinein gesteckt haben. Das
muss in den Zeitschätzungen berücksichtigt werden, wenn man mal wieder
&ldquo;Die beste Seite aller Zeiten&rdquo; bauen will.</p>
</description>
</item>
<item>
<title>Web-based frontend integration</title>
<link>https://www.innoq.com/blog/st/2014/11/web-based-frontend-integration/</link>
<pubDate>Sat, 29 Nov 2014 17:40:35 +0100</pubDate>
<guid>https://www.innoq.com/blog/st/2014/11/web-based-frontend-integration/</guid>
<description><p>So <a href="https://www.innoq.com/blog/st/2013/10/on-monoliths/">you started with a monolith</a>, and decided to split things into
smaller units. Obviously, the next thing you need to consider is how
to integrate them to form a consistent whole. To do this, let’s start
with the non-obvious part: The frontend (the UI).</p>
<p>If you look at what’s typically proposed, it seems entirely obvious
that there are two options: (1) We integrate on the client side, which
when dealing with web applications typically means using some sort of
integrating, JavaScript-based MVC framework or (2) We integrate on the
server side, using some sort of “orchestration”. (As you might have
guessed, I will be presenting a third option, the one that I actually
prefer, but let me set the stage first.)</p>
<p>Let’s start with (1), the client-side integration option, since things
like Angular.js are all the rage these days. Our goal is to create an
integrated UI, so as a first step, we can assume that if our server
just provides us with lots of small services, each of them offering an
HTTP/JSON API (RESTful or not, doesn’t really matter in this
context). Our client-side JavaScript logic will talk to multiple
services and create a composite UI based on the results. It’s the
client code’s responsibility to call the services in the right
sequence and combine their results (if all goes well) or deal with
failure (if it doesn’t). There are excellent libraries and frameworks
for doing this, and you can pick the one that best suits your taste
from the likes of Angular, Ember, and many others.</p>
<p><img src="https://www.innoq.com/blog/st/images/client.png" alt="Integration via a
client-side framework" /></p>
<p>One problem you’ll very often run into with option (1) is that the
services on the server side end up being quite fine-grained (a
consequence of their being reusable in many contexts), which leads to
a huge number of remote calls that are required between the client and
the server. Another downside typically results from the fact that you
can never rely on anything computed by the client, so you’ll have to
validate it on the server side. This, in turn, can lead to duplication
of at least parts of your logic.</p>
<p>The solution to both of these problems typically is to perform
integration, or orchestration if you prefer, on the server side –
option (2). In other words, a server-side service will invoke other,
lower-level services, taking care of combination and error handling,
interpreting the client request and returning the aggregated result in
the end. This is of course completely orthogonal to the architecture you
choose for your client, i.e. you could just as well return HTML from
your server and have a traditional, non-JS based client.</p>
<p><img src="https://www.innoq.com/blog/st/blog/st/images/server.png" alt="Integration via a server-side
orchestration service" /></p>
<p>What’s not to like? What I do not like about this approach is that you
create yet another server-side service, which makes me question why
you created the lower-level ones in the first place. This also becomes
a bottleneck, as any change to one of the lower-level services will
require a change to the orchestrating service.</p>
<p>But there’s a third option (finally!), one that doesn’t seem to even be
considered in many cases, although it is (in my not so humble opinion)
the most powerful one. This option (3) relies on an absolutely
magical concept called “link” (dumb joke, I know). To explore this, we
question one of the initial assumptions that led to having to
integrate on the client side or server side in the first place, namely
that for a web UI to be integrated, it needs to aggregate UIs from
different backend services into a single HTML page.</p>
<p>Instead, we have each service return HTML that can be rendered by the
browser – in other words, we assume that each page can be assigned to
one of the services. Of course there are lots of relations to other
things, but we simply use links to point to them. One nice side effect
of this is that it becomes much easier to ensure we have a meaningful
URI for each of the pages returned (or resources exposed, pick
whatever terminology you prefer).</p>
<p><img src="https://www.innoq.com/blog/st/images/link.png" alt="Integration via links" /></p>
<p>So option (3) leaves us with a number of self-contained web
applications that are integrated only by means of being linked to each
other. Apart from not connecting them to each other at all, I am not
aware of any sort of weaker coupling.</p>
<p>Of course you should be highly skeptical by now: How is that supposed
to be “integration”? Surely this guy isn’t serious? Is he seriously
suggesting we revert back to a model that was hip a decade or two ago?
You bet I am, and I’ll explore some of your doubts in a future post.</p>
</description>
</item>
<item>
<title>Minor Blog Updates, and Where Have the Comments Gone?</title>
<link>https://www.innoq.com/blog/st/2014/11/minor-blog-updates-and-where-have-the-comments-gone/</link>
<pubDate>Tue, 18 Nov 2014 21:13:00 +0100</pubDate>
<guid>https://www.innoq.com/blog/st/2014/11/minor-blog-updates-and-where-have-the-comments-gone/</guid>
<description><p>First of all, you’re likely only reading this because you’re one of
the few remaining souls who rely on RSS/Atom to follow a blog, just
like I do. That’s great! And I apologize for messing with your feed
(it’s quite likely a whole bunch of articles were marked as unread in
your feedreader, something I hate when it happens to me). Sorry.</p>
<p>As you can see (or could see if you bothered to visit the site, which
you probably don’t as it provides a full-text feed so why would you? I
know I wouldn’t), I have tweaked the design a bit to align it a bit
more with our <a href="https://www.innoq.com/en/">main company site</a>, which I
happen to like quite a bit. I also included nicely unobtrusive,
<a href="http://schier.co/blog/2014/10/22/pure-html-share-buttons.html">pure HTML share buttons</a>
(because I keep hearing people like them and didn’t want to include
more JavaScript code provided by a party interested in tracking your
every move then absolutely necessary). Most importantly, the fact that
the whole site is now delivered via HTTPS only is reflected in the
URIs used as IDs for the posts, which is likely the change that
triggered that unread mark.</p>
<p>I will try to treat you better in the future, fellow Atom die-hard.</p>
<p>In the same spirit (less JS), I also removed the Disqus comments. I
love the idea of Disqus (externalized comments), but I hate the
implementation. But if you have feedback to some of the stuff I write,
feel free to <a href="mailto:stefan.tilkov@innoq.com">write me an email</a>! I might not answer immediately (or
rarely not at all), but I’ll try to incorporate whatever you send me
into future posts.</p>
</description>
</item>
<item>
<title>How small should your microservice be?</title>
<link>https://www.innoq.com/blog/st/2014/11/how-small-should-your-microservice-be/</link>
<pubDate>Mon, 17 Nov 2014 07:53:00 +0100</pubDate>
<guid>https://www.innoq.com/blog/st/2014/11/how-small-should-your-microservice-be/</guid>
<description><p>Given that microservices are supposed to be, well, “micro”, there’s a
lot of discussion about the right size. A typical answer to this
question is: A microservice should do just one thing. I don’t really
think that’s an answer, as “one thing” leaves a lot of room for
interpretation. But I’ve seen people suggest that each individual
microservice should be as small as a single function, and I strongly
disagree with this for almost every situation. Consider, for example,
a function that computes something based on three input values, and
returns a result. Is that a good candidate for a microservice,
i.e. should it be a separately deployable application of its own?</p>
<p>I believe it’s easier to approach this from the opposite
direction. Let’s take an example: A web-based email system. Let’s not
overcomplicate things and assume it’s traditional and offers the
minimal features you’d expect, such as logging in and out, maintaining
some user settings, creating messages (from scratch or by replying to
or forwarding an existing one), deleting messages, viewing your inbox,
moving messages into folders (that you can create, view and delete),
maintaining an address book, search for messages … I’m sure you get
the picture. At one extreme, we could absolutely build this as a
single application and ensure it’s built not as a single package, but
using a reasonable internal modularization strategy. We could decide
to write its core as a set of collaborating classes, maybe adhering to
the DDD approach (which would classify the classes according to the
role they play). Then we’d add the dependencies to the outside world,
such as the UI, the data storage, external systems (such as maybe
external mail handlers, LDAP directories, etc.), possibly using a
layered or hexagonal architecture.</p>
<p>The team(s) working on this application would need to synchronize very
tightly, as the whole thing is released at once. It will also be
scalad in an all-or-nothing fashion, and it will be down or up and
running completely, not partially. That may be perfectly fine! But
let’s just assume (again) you deem it’s not, and want to cut it apart
into separate parts that have their own life-cycle and are isolated
from each other.</p>
<p>How would you go about decomposing this into separate applications or
services? First of all, the login/logout stuff (the auth system) is
a good candidate, as is the user profile. They could go into one
service, but if we consider that the auth system has to maintain
passwords (or rather, password hashes), it makes sense in my view to
treat it differently from the rest. The emails and folders themselves
seem quite cohesive to me, though: You could separate them, but I
probably wouldn’t. If there are multiple ways to connect to the
outside world, say, via the Web interface, POP3, IMAP, and SMTP, I can
imagine each of those being their own service. Maybe I’d factor out
the storage of messages into its own service, one that doesn’t know
the difference between a document and an email. I think the address
book, including its data storage, its UI and its API seems like a
natural candidate to be separated from the rest.</p>
<p>But in all, I’d probably end up with a dozen, maybe twenty or thirty
services (or <em>self-contained systems</em>, as I prefer to call them). And
more importantly, I think that for any given interaction triggered by
some outside event – like e.g. a user clicking a button after entering
data into a form – I’d end up touching maybe 3-5 of them.</p>
<p>In other words, I think it’s not a goal to make your services as small
as possible. Doing so would mean you view the separation into
individual, stand-alone services as your <em>only</em> structuring
mechanism, while it should be only one of many.</p>
</description>
</item>
<item>
<title>Just do it</title>
<link>https://www.innoq.com/blog/st/2014/11/just-do-it/</link>
<pubDate>Mon, 10 Nov 2014 20:20:00 +0100</pubDate>
<guid>https://www.innoq.com/blog/st/2014/11/just-do-it/</guid>
<description><p>Three posts in quick succession: <a href="http://scribbling.net/2014/10/16/short-form-blogging/">This one</a> by Gina Trapani, <a
href="http://sixcolors.com/post/2014/10/bigger-than-a-tweet/">this one</a> by Jason Snell, and <a
href="http://www.marco.org/2014/11/01/short-form-blogging">this one</a> from Marco Arment, all make the same point: There should be more blogging, and maybe one way to get this into real, live, actual posts is to reduce the amount of rules you as a writer subject yourself to. In this spirit, I’ll try to get this thing restarted.</p>
</description>
</item>
<item>
<title>Women in Tech</title>
<link>https://www.innoq.com/blog/st/2014/08/women-in-tech/</link>
<pubDate>Mon, 04 Aug 2014 18:13:00 +0100</pubDate>
<guid>https://www.innoq.com/blog/st/2014/08/women-in-tech/</guid>
<description><p>For a long time, I’ve been convinced that we need more women, or in general, a lot more diversity, in the tech community. While I’m typically not at a loss for words on any topic, I find this one pretty hard. My guess is the major reason is that my own perspective on this is constantly changing. In fact I’m quite convinced that if I spoke to a version of myself that had been transported to the present from, say, 5 years ago, I’d disagree with me a lot. And there are a lot of capable people writing and talking about this topic already, more than enough to ensure my input is not really needed.</p>
<p>On the other hand, though, I know that sometimes it’s easier to listen to someone from your own demographic, and accept that they expose a point of view you disagree with, so maybe I should say something from time to time. And I haven’t put this blog to good use for a while, so why not start with this topic? I’d be extremely interested in getting your feedback, so please do use the comments or let me know what you think via Twitter.</p>
<p>First of all, to set up a bit of a foundation, here are some of the things I consider to be and personally have no doubts about at all:</p>
<ul>
<li>There is no inherent reason at all why men should be better at technical tasks than women (or vice versa).</li>
<li>The software community (or IT/tech industry, if you prefer) does not have a remotely reasonable share of women.</li>
<li>The reason for this is a complex mixture of
a) things that happen in our education system, very early in peoples’ lives, that make women pursue a different career
b) things that the tech industry does that make it unattractive for women
c) things the tech industry does that drive women who do enter it into leaving it again</li>
<li>Whatever the reasons may be, the effect is undoubtedly negative because
a) there is a lot on unused potential, i.e. there could be almost double the number of great programmers if it weren’t mostly men who worked in this industry and
b) a more diverse group is way more fun to work with and (if studies are to be believed) more productive</li>
<li>A lot of the discussion about women is equally applicable to other groups, such is people with disabilities, minority ethnic groups, LGBT folks, etc.</li>
</ul>
<p>Do you disagree with any of these?</p>
</description>
</item>
<item>
<title>On Monoliths</title>
<link>https://www.innoq.com/blog/st/2013/10/on-monoliths/</link>
<pubDate>Tue, 22 Oct 2013 10:47:00 +0100</pubDate>
<guid>https://www.innoq.com/blog/st/2013/10/on-monoliths/</guid>
<description><p>A while ago, I gave a talk at QCon about breaking up monoliths
(<a href="http://www.infoq.com/presentations/Breaking-the-Monolith" title="Breaking the Monolith">there&rsquo;s a video up on InfoQ</a>), repeated it in a slightly improved version
at JavaZone (see
<a href="https://speakerdeck.com/stilkov/breaking-the-monolith-1">slides</a> and
<a href="http://vimeo.com/74354372">video</a>), and the topic continues to come
up in almost every consulting engagement and client workshop I&rsquo;ve been
involved in since then. Like many of the topics I talk about, it&rsquo;s
somewhat unfair that I get the positive feedback and people assume I
came up with the ideas all on my own: Most of stuff like this is the
result of collaboration, with my colleagues at <a href="http://www.innoq.com">innoQ</a> (see for
example
<a href="http://www.sigs-datacom.de/fachzeitschriften/objektspektrum/online-themenspecials/artikelansicht.html?tx_mwjournals_pi1%5Bpointer%5D=0&amp;tx_mwjournals_pi1%5Bmode%5D=1&amp;tx_mwjournals_pi1%5BshowUid%5D=7022">an article I wrote with Phillip Ghadir for ObjektSpektrum</a>
if you read German), as well as customer staff. But wherever it
originated, I found that it strikes a nerve with many developers and
architects, not only in big companies that conduct million-Euro
development projects, but also in smaller e-commerce companies and
even startups that have started to become successful.</p>
<p>The main idea is this (no surprise for almost everyone, I guess):
<em>Nobody</em> wants monoliths, i.e. big systems composed of hundreds of
thousands or millions of lines of code (in a language like Java) or
tens of thousands (e.g. in Ruby), yet everyone ends up having
them. And once you have one, you&rsquo;re basically stuck with them: They&rsquo;re
incredibly hard to maintain, extend, and modernize; yet they provide
value and can&rsquo;t simply be replaced (something that many organizations
attempt but fail at, because it&rsquo;s awfully hard to create something new
that is not only great in terms of architecture, but also can actually
function as a full replacement for all of the old system&rsquo;s features.</p>
<p>So what&rsquo;s the proposed remedy? To talk about that, we need to take a
step back and find out how we actually end up systems that are too big
in the first place. My theory is that the number one reason is <em>project
scope</em>.</p>
<p>When a project is started, there is an assumption that it&rsquo;s the goal
of a project to create a single system. This typically goes
unquestioned, even though the people or person coming up with the
project boundaries often don&rsquo;t decide this consciously. This is most
obvious if they&rsquo;re non-technical people who make decisions on a budget
basis.</p>
<p>So the very first thing we should be doing as architects (or lead
developers if you don&rsquo;t like the term) is to find out what it actually
is we should be building. Is it really a single system? If our task is
to replace an existing system with a new one, it&rsquo;s very tempting to
just accept existing boundaries and go with them. If we&rsquo;re
consolidating two systems, it&rsquo;s equally tempting to view our scope as
the union of the predecessor systems&rsquo; scope. In the rare cases where
our task is to actually modularize something existing, it&rsquo;s because of
business reasons (such as deregulation). Again, while it might seem
like a good idea to just accept the boundaries being suggested to us,
it&rsquo;s not at all clear why this should be a good idea. After all,
if whoever came up with those boundaries is not an architect or
developer, what makes us think they made a good choice?</p>
<p>In my view, the most important thing to do, then, is to find out how
many systems we should be building in the first place. It may be a
single one, but it may also be two, five or a dozen (though probably
not more) &ndash; clearly, the decision should be made very consciously,
because whatever system boundaries you pick, you will likely be stuck
with them for a very long time.</p>
<p>As &ldquo;system&rdquo; is a term that can mean almost anything, I need to define
what I mean by it in this context. A system is an independent unit
that is developed according to its own rules, and only connected to
other systems in an unobstrusive fashion. A system, according to this
model, has its own database, business logic, and user interface; it&rsquo;s
deployed separately. It&rsquo;s likely developed by a different team than
other systems. It has its own life cycle, in terms of development as
well as deployment. It&rsquo;s operated autonomously. It has its own test
suite. In basically every regard, it&rsquo;s as different from all the other
systems as a piece of commercial off-the-shelf software would be. (In
fact, one of the systems may end up being a piece of standard
software.) Is that the same as the &ldquo;Micro Services&rdquo; idea? If you watch
James Lewis&rsquo;s great talk
(<a href="http://vimeo.com/74452550">here&rsquo;s a recording</a>, also done at
JavaZone; in fact his was scheduled directly after mine), you&rsquo;ll find
a lot of similarities, but the major difference is probably the size
of each individual unit. But to me, seeing similar concepts appear in
different contexts is a very good sign.</p>
<p>It doesn&rsquo;t really matter that much whether you get the number and
distribution right with the first attempt &ndash; in fact, you can
reasonably consider that to be highly improbable. But it&rsquo;s one thing
to find out you should have built six or eight systems instead of seven,
i.e. get it wrong in one or two places, and a completely different one
to notice it should have been seven instead of one.</p>
<p>I&rsquo;ve rambled on for long enough for a single post, so here&rsquo;s a
preliminary conclusion: How many systems you build should be a very
conscious decision. It will affect the life of those tasked with
evolving and maintaining it for years to come.</p>
</description>
</item>
<item>
<title>Harassed by Getty Images</title>
<link>https://www.innoq.com/blog/st/2013/10/harassed-by-getty-images/</link>
<pubDate>Mon, 07 Oct 2013 11:52:00 +0100</pubDate>
<guid>https://www.innoq.com/blog/st/2013/10/harassed-by-getty-images/</guid>
<description><p>Ah, the joys of &ldquo;Intellectual Property&rdquo;. I&rsquo;ve been a long-time fan of the wonderful demotivational posters offered by <a href="http://www.despair.com">despair.com</a>. From time to time, I point people to them, e.g. by tweeting about it. In the past, when there was no Twitter (yes, that time existed), I used this blog to do so &ndash; on one occasion not only using a plain <code>&lt;a&gt;</code>, but an <code>&lt;img&gt;</code> element as well, embedding one of their images on this site (<a href="https://www.innoq.com/blog/st/2006/01/demotivation.html">this</a> is the post minus the image). After all, why not send a little traffic to these fine folks?</p>
<p>But obviously Despair uses stock photos &ndash; a perfect use case if there ever was one &ndash;, and the rights to the particularly cheesy ones apparently belong to Getty images. Now I&rsquo;ve received a letter, first from their internal legal department, and &ndash; after explaining the misunderstanding on their part &ndash; now from their lawyer. In both cases, they insist that we need to license the image to use it.</p>
<p>As I didn&rsquo;t copy the image of the poster, but only link to it, this seems entirely absurd to me &ndash; particularly if Despair properly licensed the image, which I&rsquo;m quite sure of. (If at all, Despair might have more reason, but I can&rsquo;t believe they&rsquo;d be that unreasonable, purely out of their own interest.) But my guess is the legal trolls at Getty believe it won&rsquo;t be worth the hassle to me. They&rsquo;re wrong &ndash; I don&rsquo;t believe they deserve a single cent of my (or the company&rsquo;s) money. If you have any advice, or want to share some of your own experience with these people, please leave a comment.</p>
</description>
</item>
<item>
<title>Keyboard Optimization</title>
<link>https://www.innoq.com/blog/st/2013/06/keyboard-optimization/</link>
<pubDate>Sun, 30 Jun 2013 21:19:00 +0100</pubDate>
<guid>https://www.innoq.com/blog/st/2013/06/keyboard-optimization/</guid>
<description><p>For the last few months, I&rsquo;ve been continuously tweaking my laptop
settings to optimize my typing speed and efficiency. Here are some of
the things I&rsquo;ve learned, and some of the tools and approaches I&rsquo;m
currently using.</p>
<ul>
<li><p>I finally took up &ldquo;real&rdquo; touch typing, i.e. using 10 fingers and a
classical system. For years I&rsquo;d been quite satisfied, even a little
proud, of my awesome typing skillz, only to be shot down when I took
the first real speed typing test and found myself scoring a ridiculous 30-40
words per minute, the reason being mostly mistakes and the
&ldquo;occasional&rdquo; peeking if some not-so-common character came along. There
are a ton of tools for learning touch typing. The one I spent the most
time with is the excellent (and free) <a href='http://www.tipp10.com/en/index/'>Tipp10</a>, which is available in
both offline and online versions. There&rsquo;s also the very nicely done
<a href='https://itunes.apple.com/en/app/keys/id526394170?mt=12'>Keys</a> if you&rsquo;re on a Mac and have a US keyboard. If you like to have
some social interaction, both <a href='http://10fastfingers.com/'>10 Fast Fingers</a> and <a href='http://play.typeracer.com/'>Typeracer</a> are also
quite nice. Finally, for a programmer, <a href='http://typing.io/'>typing.io</a> is a fantastic resource.</p></li>
<li><p>I switched to a US keyboard layout a while ago. I don&rsquo;t know why
I&rsquo;d put this off for so long; while I originally started out using a
German keyboard layout (QWERTZ instead of QWERTY), I easily write half
of what I produce in English, so it wouldn&rsquo;t have hurt to do this
earlier. The most important benefits are that almost all of the
characters required in programming languages are far easier to type
using a US keyboard and all of the keyboard shortcuts, particularly in
editors such as my favorite, Emacs, suddenly make a lot more
sense. Because I still type a lot of German texts and hated the
default input method for umlauts and the German &ldquo;&szlig;&rdquo;, I installed <a
href='http://hci.rwth-aachen.de/USGermanKeyboard'>the great &ldquo;USGerman&rdquo; keyboard layout</a>, which allows me to use Option+a, u, o and s to
get the appropriate characters with a single combination. This has
turned out to be a very workable solution.</p></li>
<li><p>It also made me use Cmd for Meta in Emacs, which is both good and bad:
It&rsquo;s good because when you use Emacs, you use Meta a lot; it&rsquo;s bad,
because some of the keyboard shortcuts for moving around now need to
be done with Cmd (in Emacs) and Option (everywhere else), which can be
a bit annoying. Also, I ordered my new laptop with a German keyboard
layout by accident, which ended up being great because it means I now
have no chance to actually look at the keyboard for those special
characters anymore. (It also allowed me to turn the keyboard lighting
all the way down.)</p></li>
<li><p>Speaking of Emacs, I wanted to make sure I have the Emacs short
cuts available everywhere. This is actually the case to a large degree
by default on a Mac, but I wanted to be able to rely on combinations
such as Ctrl-M, Ctrl-H, Ctrl-I, etc. Enter the slightly ugly, stupidly
named, but incredibly powerful <a href='https://pqrs.org/macosx/keyremap4macbook/index.html.en'>KeyRemap4MacBook</a>, which allowed me to
ensure Emacs keys work everywhere. (I hear this is possible for vi
users, too.)</p></li>
</ul>
<p>Now I find myself not taking my fingers off home row very much, and I&rsquo;m
comfortably moving along at 60-80 wpm. There&rsquo;s a weird satisfaction in
this &ndash; I noticed that in a recent company-internal discussion, many
of my co-workers did not seem to see much of a point in taking up
touch-typing because they don&rsquo;t see typing speed as the limiting
factor. One reason I might see this differenly is because I (sadly) don&rsquo;t
program much these days, but produce a lot of prose instead. And there, at
least, I&rsquo;m absolutely confident that not having your typing get in the
way is a huge asset.</p>
</description>
</item>
<item>
<title>Why I like Schemaless Data Structures</title>
<link>https://www.innoq.com/blog/st/2013/01/why-i-like-schemaless-data-structures/</link>
<pubDate>Mon, 07 Jan 2013 23:00:00 +0100</pubDate>
<guid>https://www.innoq.com/blog/st/2013/01/why-i-like-schemaless-data-structures/</guid>
<description><p>Martin Fowler has written an infodeck (which is actually a nice format for these kinds of things) <a href='http://martinfowler.com/articles/schemaless/'>on schemaless databases and in-memory structures</a>. I agree with most of it, at least as far as database design is concerned. But I believe there are two important concerns missing, and that&rsquo;s the reason why I don&rsquo;t agree with the conclusion. Note that my concern is not really with the database part, but with the extrapolation to in-memory data structures, so you should read the following with this in mind:</p>
<p>First, a major effect of using &ldquo;schemaless&rdquo;, simple data structures is loose&reg; coupling between pieces of logic (functions) operating on them. If I pass a map to a piece of code, that code will extract what it&rsquo;s interested in, possibly transforming the data in the process (ideally into a new data structure using efficient copy strategies). It will thus only depend on what it actually uses. Take the following Clojure code as an example (this would be doable similarly in Python, Ruby, Perl, Scala and even Java, although with way more boilerplate in it).</p>
<pre><code>;; &quot;projects&quot; is a Clojure set containing three maps
(def projects #{
{:id &quot;1&quot;,
:kind :time-material,
:description &quot;Consulting for BigCo&quot;,
:budget 25000,
:team [:joe, :chuck, :james]}
{:id &quot;2&quot;,
:kind :fixed-price,
:description &quot;Development for Startup&quot;,
:budget 100000,
:team [:john, :chuck, :james, :bill]}
{:id &quot;3&quot;,
:kind :fixed-price,
:description &quot;Clojure Training&quot;,
:budget 3000,
:team [:joe, :john]}})
;; all-members returns all team members in all projects
(defn all-members
[projects]
(reduce conj #{} (flatten (map :team projects))))
;; yields #{:chuck :joe :james :john :bill}
</code></pre>
<p>The code and the data structure are coupled just by one map key (<code>:team</code> in the example); I can add other data elements without problems as long as I maintain that contract. In languages such as Clojure, a huge library of useful functions to manipulate data rely on this fact (<code>conj</code>, <code>flatten</code>, <code>map</code> and <code>reduce</code> in this case.)</p>
<p>More importantly, it&rsquo;s possible (and actually quite common) to use generic data structures at boundaries, such as between modules/namespaces. At their interfaces, these modules accept simple data structures, not complex object graphs. In fact this makes it a lot easier to evolve a single-process program into a distributed one: The kinds of interfaces you use internally resemble what you&rsquo;d be using remotely (in fact there&rsquo;s a very nice mapping between a nested Clojure, Ruby or Python data structure and e.g. JSON.)</p>
<p>Some languages, such as Clojure, take this to an extreme: Almost everywhere you&rsquo;d create a new class in an OO language, you&rsquo;d just use a simple data structure, such as map, a vector, set or list. In a statically typed limited OO language such as Java, you will almost always end up creating new classes. Of course you can use Map in Java, too, but it would not be idiomatic (and the reverse is true for Clojure as well, which enables you to create &ldquo;normal&rdquo; Java classes, too.) Some languages are somewhere in the middle, as shown by the Ruby code in Martin&rsquo;s example. But I find it not very useful to favor one style over the other by default, unless you consider the language you&rsquo;re using.</p>
<p>Secondly, the use of custom-built data structures &ndash; and that&rsquo;s what a schema boils down to if viewed from a programming language standpoint &ndash; always means additional code. You might consider this irrelevant, but it&rsquo;s nicely shown in interfaces such as those of WSGI, Rack or Ring when you compare them to their equivalent in Java: A simple map containing a method or response code, headers and a body vs. different concrete classes for requests with tons of specific attributes (and bonus getters and setters). Restricting the use of schemaless design to the cases where you actually need dynamic variability misses this advantage.</p>
<p>In summary, I think of Martin&rsquo;s points are valid, and he definitely spent more time on articulating his conclusion than I did in writing this comment. But I think those two aspects &ndash; coupling and verbosity &ndash; are worth considering when you need to decide which approach to use.</p>
</description>
</item>
<item>
<title>New languages</title>
<link>https://www.innoq.com/blog/st/2012/12/new-languages/</link>
<pubDate>Sat, 22 Dec 2012 15:00:00 +0100</pubDate>
<guid>https://www.innoq.com/blog/st/2012/12/new-languages/</guid>
<description><p>Being a programming language geek, I typically try to use the
Christmas vacation to learn (or rather, play with) a programming
language I don&rsquo;t know. This year, I find this very hard, as there are
so many interesting languages one could spend time with. Some I have
considered are:</p>
<ul>
<li>Go: I was thoroughly unimpressed with this language when it came
out, and I still fail to see a lot of interesting stuff in it. But
I&rsquo;ve heard many people I respect say only good things about their
experience with it, so maybe I should reconsider.</li>
<li>Rust: At first glance, this seems to be a very nicely designed
language (and it has a really excellent tutorial). Even though its
language features are very advanced, it seems to be intended for
low-level use cases (that I mostly don&rsquo;t have).</li>
<li>Fantom: Seems to be interesting, too; I remember I looked at it
a long time ago, but never in depth.</li>
</ul>
<p>What do you think? What else is worth a look?</p>
</description>
</item>
</channel>
</rss>
If you would like to create a banner that links to this page (i.e. this validation result), do the following:
Download the "valid RSS" banner.
Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)
Add this HTML to your page (change the image src
attribute if necessary):
If you would like to create a text link instead, here is the URL you can use:
http://www.feedvalidator.org/check.cgi?url=http%3A//www.innoq.com/blog/st/atom.xml