FEED Validator

Congratulations!

This is a valid RSS feed.

Recommendations

This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.

• line 10, column 102: Self reference doesn't match document location [help]

  ... rel="self" type="application/rss+xml" />
                                               ^

Source: http://www.innoq.com/blog/st/atom.xml

1. <?xml version="1.0" encoding="utf-8" standalone="yes" ?>
2. <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
3.  <channel>
4.    <title>Stefan Tilkov’s Blog</title>
5.    <link>https://www.innoq.com/blog/st/index.xml</link>
6.    <description>Recent content on Stefan Tilkov’s Blog</description>
7.    <generator>Hugo -- gohugo.io</generator>
8.    <language>en-us</language>
9.    <lastBuildDate>Sun, 22 Jan 2017 23:00:00 +0100</lastBuildDate>
10.    <atom:link href="https://www.innoq.com/blog/st/index.xml" rel="self" type="application/rss+xml" />
11.    
12.    <item>
13.      <title>Software Engineering Radio Update</title>
14.      <link>https://www.innoq.com/blog/st/2017/01/software-engineering-radio-update/</link>
15.      <pubDate>Sun, 22 Jan 2017 23:00:00 +0100</pubDate>
16.      
17.      <guid>https://www.innoq.com/blog/st/2017/01/software-engineering-radio-update/</guid>
18.      <description>&lt;p&gt;Good news: SE Radio &lt;a href=&#34;http://www.se-radio.net/2017/01/were-listening/&#34;&gt;has decided to stop the ad&lt;/a&gt; I was offended by, and
19. will even remove it from past episodes. I think that is pretty great
20. for the show’s listeners and for the show itself.</p>
21.  
22. <p>As for me, I won’t return to the show. We’re parting on good terms, no
23. hard feelings on either side. On the contrary: I encourage you to
24. listen to the show – I know I will continue to do so, it’s pretty
25. great.</p>
26.  
27. <p>Nevertheless, I’ll be taking the chance to start a new podcast,
28. together with a few of my former show hosts and some esteemed
29. co-workers. Preparations are progressing smoothly, and I expect I’ll
30. be able to announce something over the next few days.</p>
31. </description>
32.    </item>
33.    
34.    <item>
35.      <title>No More End-to-End-Cyber: Why I&#39;ve Resigned from Software Engineering Radio</title>
36.      <link>https://www.innoq.com/blog/st/2017/01/no-more-end-to-end-cyber-why-ive-resigned-from-software-engineering-radio/</link>
37.      <pubDate>Sat, 14 Jan 2017 18:00:00 +0100</pubDate>
38.      
39.      <guid>https://www.innoq.com/blog/st/2017/01/no-more-end-to-end-cyber-why-ive-resigned-from-software-engineering-radio/</guid>
40.      <description>&lt;p&gt;I&amp;rsquo;ve just announced my resignation from &lt;a href=&#34;http://www.se-radio.net&#34;&gt;Software Engineering Radio&lt;/a&gt;, a podcast I&amp;rsquo;ve been involved with for quite some time.&lt;/p&gt;
41.  
42. <p>The TL;DR of the explanation: I refuse to have ads from US arms manufacturers placed into a podcast against my will.</p>
43.  
44. <p>I first appeared as a guest on SE Radio talking about REST
45. <a href="http://www.se-radio.net/2008/05/episode-98-stefan-tilkov-on-rest/">a very long time ago</a>,
46. interviewed by <a href="http://www.voelter.de">Markus Völter</a>, the podcast’s
47. founder. I joined again as a guest
48. <a href="http://www.se-radio.net/2014/09/episode-210-stefan-tilkov-on-architecture-and-micro-services/">talking about monoliths and microservices</a>,
49. before becoming one of the hosts. I recorded a number of episodes with
50. an amazingly great set of guests, including
51. <a href="http://www.se-radio.net/2016/07/se-radio-episode-263-camille-fournier-on-real-world-distributed-systems/">Camille Fournier</a>,
52. <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>,
53. <a href="http://www.se-radio.net/2016/05/se-radio-episode-257-michael-nygard-on-clojure-in-practice/">Michael Nygard</a>,
54. <a href="http://www.se-radio.net/2016/05/se-radio-episode-256-jay-fields-on-working-effectively-with-unit-tests/">Jay Fields</a>,
55. <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>,
56. <a href="http://www.se-radio.net/2015/11/se-radio-episode-241-kyle-kingsbury-on-consensus-in-distributed-systems/">Kyle Kingsbury</a>,
57. <a href="http://www.se-radio.net/2015/07/episode-232-mark-nottingham-on-http2/">Mark Nottingham</a>,
58. and
59. <a href="http://www.se-radio.net/2014/12/episode-216-adrian-cockcroft-on-the-modern-cloud-based-platform/">Adrian Cockcroft</a>. I
60. enjoyed the chance to spend time talking to my guests tremendously,
61. and I’m pretty sure quite a few listeners enjoyed the results, too.</p>
62.  
63. <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>
64.  
65. <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>
66.  
67. <p>I might have tolerated this, but the straw that broke the camel’s back
68. were some discussions about editorial policies regarding politics and
69. ethics discussions in the podcasts itself. This, in combination with
70. running an ad for technology for today’s battlefield (which, you know,
71. “is increasingly cyber”), was just too much.</p>
72.  
73. <p>Sadly, SE Radio is now part of the IEEE Computer Society, an
74. organization with strong ties to the US military and its vendors, and
75. my and some other hosts’ attempts to do anything about this led to no
76. resolution. The IEEE CS is free to not care about the views of its
77. hosts. I’m free to spend my free time somewhere else.</p>
78.  
79. <p>Which is actually something I’m currently actively planning on doing;
80. stay tuned for some podcast-related news sometime soon.</p>
81. </description>
82.    </item>
83.    
84.    <item>
85.      <title>Don’t start with a monolith</title>
86.      <link>https://www.innoq.com/blog/st/2015/06/dont-start-with-a-monolith/</link>
87.      <pubDate>Mon, 08 Jun 2015 12:12:00 +0100</pubDate>
88.      
89.      <guid>https://www.innoq.com/blog/st/2015/06/dont-start-with-a-monolith/</guid>
90.      <description>&lt;p&gt;I’ve been an avid follower of Martin Fowler’s work ever since I read
91. <a href="https://books.google.de/books/about/Analysis_Patterns.html?id=4V8pZmpwmBYC&redir_esc=y">“Analysis Patterns”</a> almost 20 years ago. I’ve always appreciated the
92. way he manages to distill complex topics down to their essence, and I
93. think the immense number of people reading <a href="http://martinfowler.com">martinfowler.com</a> is well
94. deserved. I’m also lucky to have met Martin in person numerous times and was
95. thus able to discuss many of the topics we share an interest in with
96. him.</p>
97.  
98. <p>Therefore I couldn’t be more pleased to have been able to publish
99. <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>
100. </description>
101.    </item>
102.    
103.    <item>
104.      <title>Thoughts on a Canonical Data Model</title>
105.      <link>https://www.innoq.com/blog/st/2015/03/thoughts-on-a-canonical-data-model/</link>
106.      <pubDate>Mon, 30 Mar 2015 12:12:00 +0100</pubDate>
107.      
108.      <guid>https://www.innoq.com/blog/st/2015/03/thoughts-on-a-canonical-data-model/</guid>
109.      <description>&lt;p&gt;Over on the innoQ company blog, I&amp;rsquo;ve published a post on why I believe a canonical data model is a bad idea. &lt;a href=&#34;https://www.innoq.com/en/blog/thoughts-on-a-canonical-data-model/&#34;&gt;Enjoy&lt;/a&gt;.&lt;/p&gt;
110. </description>
111.    </item>
112.    
113.    <item>
114.      <title>Wenn AngularJS eine schlechte Idee ist</title>
115.      <link>https://www.innoq.com/blog/st/2014/12/wenn-angularjs-eine-schlechte-idee-ist/</link>
116.      <pubDate>Thu, 04 Dec 2014 11:23:00 +0100</pubDate>
117.      
118.      <guid>https://www.innoq.com/blog/st/2014/12/wenn-angularjs-eine-schlechte-idee-ist/</guid>
119.      <description>&lt;p&gt;&lt;em&gt;Mein Kollege Sebastian Janzen, seines Zeichens bekennender
120. AngularJS-Fan, hat den folgenden Text in seinem internen Blog
121. gepostet – und ich konnte es mir nicht verkneifen, ihn zu fragen, ob
122. ich ihn als Gast-Post hier veröffentlichen darf. Hier also seine
123. (weisen) Worte …</em></p>
124.  
125. <p>Ich habe nun mehrmals zwei Phänomene beobachtet: Ein Entscheider - je
126. größer die Firma desto eher zutreffend - hat keine Lust mehr, in die
127. gelangweilten, von Prozess-Narben geprägten Gesichter seiner
128. Entwickler zu schauen. Er möchte das Team positiv überraschen und überträgt
129. für das nächste Projekt AngularJS von einer Buzzword- in die
130. Requirements-Liste, denn Entwickler möchten endlich mal was Cooles
131. machen. In einem Meeting für eine neue Webseite packt er stolz den
132. heiligen SPA-Gral AngularJS aus. Alle Probleme sind gelöst, die
133. Entwickler sind happy, das kommt in die Requirements.</p>
134.  
135. <p>Und nun wird noch jemand von innoQ dazu geholt und hinterfragt
136. kritisch das Entwickler-Glück. “AngularJS? Sie wissen schon, dass dies
137. an der Stelle nicht so ganz zu Ihrem Problem passt?”</p>
138.  
139. <p>So sehr ich Angular mag und es im ein oder anderen Bereich für richtig
140. halte eine SPA zu bauen, so fatal kann es auch laufen, wenn man damit
141. versucht Probleme zu erschlagen, die gegensätzlicher nicht sein
142. könnten. Beispiele:</p>
143.  
144. <ul>
145. <li><p><em>Meine Anwendung soll rasend schnell sein!</em> <br/> Ja, das kann sie als SPA
146. sein, jedoch nicht, wenn man zwischen dieser und anderen Seiten
147. ständig hin und her wechselt. Ein OpenID-Provider liefert in der Regel
148. zwei Seiten aus: Login und Success + Redirect. Die Aufenthaltsdauer
149. muss eine SPA rechtfertigen! Und für den Besucher ist es egal, ob es
150. eine technisch perfekte Seite ist. Das wird seine Aufenthaltszeit
151. nicht verlängern, sondern verkürzen.</p></li>
152.  
153. <li><p><em>Die coolen Seitenübergänge gehen nur in Angular!</em> <br/>  Nein, die sind
154. mit CSS erzeugt oder im Fallback mit jQuery.animate. Genau dieser
155. Technik bedient sich Angular auch, denn es ist in JavaScript
156. geschrieben - nicht mehr und nicht weniger. Es hat weder Zugriff auf
157. Hardware, noch kann es den IE 8 zu einem coolen Browser machen.</p></li>
158.  
159. <li><p><em>Bei Angular muss ich mich nicht mehr um den DOM kümmern</em> <br/>  Uiuiui,
160. als ich das mal gehört habe hat sich bei mir alles rumgedreht. Ich
161. glaube ich habe in meiner Angular-Zeit noch nie so viel über die
162. Verzahnung zwischen DOM und JS gelernt - einfach aus der Not heraus,
163. Bugs zu finden. Manch einer erschlägt diese Bugs mit genügend
164. Timeouts. Und viele Plugin-Entwickler machen das auch so, aber das ist
165. ziemlich weit weg von geil. Und vom eigentlichen
166. Performance-Ziel. Grundkonzepte wie Asynchronität in einem Browser
167. müssen verstanden werden, nicht hintergangen! Aus meiner Sicht geht
168. Angular mit diesem Umstand hervorragend um, es muss nur genutzt
169. werden.</p></li>
170.  
171. <li><p><em>Wir haben viel Angular-Erfahrung im Team</em> <br/>  Sicher? Unterhaltet Euch
172. vorher mit dem Team, stellt Fragen, was die do’s und don’ts sind. Wenn
173. da nichts kommt oder die Frage “Wofür setzt man Angular nicht ein?”
174. unbeantwortet bleibt, dann haben diese Menschen nicht viel damit
175. gemacht. Da ist eine Lernphase von teilweise mehreren Wochen
176. einzuplanen und viel Debugging-Zeit. Eine schöne Frage ist auch “Was
177. sind Promises?”</p></li>
178.  
179. <li><p><em>Dieses Angular ist nur Frontend, dafür plane ich als Senior
180. Consultant mal zwei Stunden ein</em> <br/>  Das wird scheitern. Angular ist ein
181. Framework, mit dem man tatsächlich eine Frontend-Architektur, die
182. diesem Namen auch gerecht wird, aufsetzen und planen kann. Es gibt
183. mehr als nur Data-Binding und Routen!</p></li>
184. </ul>
185.  
186. <p>Performante SPAs, die in allen modernen Browsern und im IE >= 8 laufen
187. sind das Werk von Menschen, die sich durch und durch mit der Materie
188. beschäftigt haben und sehr viel Arbeit dort hinein gesteckt haben. Das
189. muss in den Zeitschätzungen berücksichtigt werden, wenn man mal wieder
190. “Die beste Seite aller Zeiten” bauen will.</p>
191. </description>
192.    </item>
193.    
194.    <item>
195.      <title>Web-based frontend integration</title>
196.      <link>https://www.innoq.com/blog/st/2014/11/web-based-frontend-integration/</link>
197.      <pubDate>Sat, 29 Nov 2014 17:40:35 +0100</pubDate>
198.      
199.      <guid>https://www.innoq.com/blog/st/2014/11/web-based-frontend-integration/</guid>
200.      <description>&lt;p&gt;So &lt;a href=&#34;https://www.innoq.com/blog/st/2013/10/on-monoliths/&#34;&gt;you started with a monolith&lt;/a&gt;, and decided to split things into
201. smaller units. Obviously, the next thing you need to consider is how
202. to integrate them to form a consistent whole. To do this, let’s start
203. with the non-obvious part: The frontend (the UI).</p>
204.  
205. <p>If you look at what’s typically proposed, it seems entirely obvious
206. that there are two options: (1) We integrate on the client side, which
207. when dealing with web applications typically means using some sort of
208. integrating, JavaScript-based MVC framework or (2) We integrate on the
209. server side, using some sort of “orchestration”. (As you might have
210. guessed, I will be presenting a third option, the one that I actually
211. prefer, but let me set the stage first.)</p>
212.  
213. <p>Let’s start with (1), the client-side integration option, since things
214. like Angular.js are all the rage these days. Our goal is to create an
215. integrated UI, so as a first step, we can assume that if our server
216. just provides us with lots of small services, each of them offering an
217. HTTP/JSON API (RESTful or not, doesn’t really matter in this
218. context). Our client-side JavaScript logic will talk to multiple
219. services and create a composite UI based on the results. It’s the
220. client code’s responsibility to call the services in the right
221. sequence and combine their results (if all goes well) or deal with
222. failure (if it doesn’t). There are excellent libraries and frameworks
223. for doing this, and you can pick the one that best suits your taste
224. from the likes of Angular, Ember, and many others.</p>
225.  
226. <p><img src="https://www.innoq.com/blog/st/images/client.png" alt="Integration via a
227. client-side framework" /></p>
228.  
229. <p>One problem you’ll very often run into with option (1) is that the
230. services on the server side end up being quite fine-grained (a
231. consequence of their being reusable in many contexts), which leads to
232. a huge number of remote calls that are required between the client and
233. the server. Another downside typically results from the fact that you
234. can never rely on anything computed by the client, so you’ll have to
235. validate it on the server side. This, in turn, can lead to duplication
236. of at least parts of your logic.</p>
237.  
238. <p>The solution to both of these problems typically is to perform
239. integration, or orchestration if you prefer, on the server side –
240. option (2). In other words, a server-side service will invoke other,
241. lower-level services, taking care of combination and error handling,
242. interpreting the client request and returning the aggregated result in
243. the end. This is of course completely orthogonal to the architecture you
244. choose for your client, i.e. you could just as well return HTML from
245. your server and have a traditional, non-JS based client.</p>
246.  
247. <p><img src="https://www.innoq.com/blog/st/blog/st/images/server.png" alt="Integration via a server-side
248. orchestration service" /></p>
249.  
250. <p>What’s not to like? What I do not like about this approach is that you
251. create yet another server-side service, which makes me question why
252. you created the lower-level ones in the first place. This also becomes
253. a bottleneck, as any change to one of the lower-level services will
254. require a change to the orchestrating service.</p>
255.  
256. <p>But there’s a third option (finally!), one that doesn’t seem to even be
257. considered in many cases, although it is (in my not so humble opinion)
258. the most powerful one. This option (3) relies on an absolutely
259. magical concept called “link” (dumb joke, I know). To explore this, we
260. question one of the initial assumptions that led to having to
261. integrate on the client side or server side in the first place, namely
262. that for a web UI to be integrated, it needs to aggregate UIs from
263. different backend services into a single HTML page.</p>
264.  
265. <p>Instead, we have each service return HTML that can be rendered by the
266. browser – in other words, we assume that each page can be assigned to
267. one of the services. Of course there are lots of relations to other
268. things, but we simply use links to point to them. One nice side effect
269. of this is that it becomes much easier to ensure we have a meaningful
270. URI for each of the pages returned (or resources exposed, pick
271. whatever terminology you prefer).</p>
272.  
273. <p><img src="https://www.innoq.com/blog/st/images/link.png" alt="Integration via links" /></p>
274.  
275. <p>So option (3) leaves us with a number of self-contained web
276. applications that are integrated only by means of being linked to each
277. other. Apart from not connecting them to each other at all, I am not
278. aware of any sort of weaker coupling.</p>
279.  
280. <p>Of course you should be highly skeptical by now: How is that supposed
281. to be “integration”? Surely this guy isn’t serious? Is he seriously
282. suggesting we revert back to a model that was hip a decade or two ago?
283. You bet I am, and I’ll explore some of your doubts in a future post.</p>
284. </description>
285.    </item>
286.    
287.    <item>
288.      <title>Minor Blog Updates, and Where Have the Comments Gone?</title>
289.      <link>https://www.innoq.com/blog/st/2014/11/minor-blog-updates-and-where-have-the-comments-gone/</link>
290.      <pubDate>Tue, 18 Nov 2014 21:13:00 +0100</pubDate>
291.      
292.      <guid>https://www.innoq.com/blog/st/2014/11/minor-blog-updates-and-where-have-the-comments-gone/</guid>
293.      <description>&lt;p&gt;First of all, you’re likely only reading this because you’re one of
294. the few remaining souls who rely on RSS/Atom to follow a blog, just
295. like I do. That’s great! And I apologize for messing with your feed
296. (it’s quite likely a whole bunch of articles were marked as unread in
297. your feedreader, something I hate when it happens to me). Sorry.</p>
298.  
299. <p>As you can see (or could see if you bothered to visit the site, which
300. you probably don’t as it provides a full-text feed so why would you? I
301. know I wouldn’t), I have tweaked the design a bit to align it a bit
302. more with our <a href="https://www.innoq.com/en/">main company site</a>, which I
303. happen to like quite a bit. I also included nicely unobtrusive,
304. <a href="http://schier.co/blog/2014/10/22/pure-html-share-buttons.html">pure HTML share buttons</a>
305. (because I keep hearing people like them and didn’t want to include
306. more JavaScript code provided by a party interested in tracking your
307. every move then absolutely necessary). Most importantly, the fact that
308. the whole site is now delivered via HTTPS only is reflected in the
309. URIs used as IDs for the posts, which is likely the change that
310. triggered that unread mark.</p>
311.  
312. <p>I will try to treat you better in the future, fellow Atom die-hard.</p>
313.  
314. <p>In the same spirit (less JS), I also removed the Disqus comments. I
315. love the idea of Disqus (externalized comments), but I hate the
316. implementation. But if you have feedback to some of the stuff I write,
317. feel free to <a href="mailto:stefan.tilkov@innoq.com">write me an email</a>! I might not answer immediately (or
318. rarely not at all), but I’ll try to incorporate whatever you send me
319. into future posts.</p>
320. </description>
321.    </item>
322.    
323.    <item>
324.      <title>How small should your microservice be?</title>
325.      <link>https://www.innoq.com/blog/st/2014/11/how-small-should-your-microservice-be/</link>
326.      <pubDate>Mon, 17 Nov 2014 07:53:00 +0100</pubDate>
327.      
328.      <guid>https://www.innoq.com/blog/st/2014/11/how-small-should-your-microservice-be/</guid>
329.      <description>&lt;p&gt;Given that microservices are supposed to be, well, “micro”, there’s a
330. lot of discussion about the right size. A typical answer to this
331. question is: A microservice should do just one thing. I don’t really
332. think that’s an answer, as “one thing” leaves a lot of room for
333. interpretation. But I’ve seen people suggest that each individual
334. microservice should be as small as a single function, and I strongly
335. disagree with this for almost every situation. Consider, for example,
336. a function that computes something based on three input values, and
337. returns a result. Is that a good candidate for a microservice,
338. i.e. should it be a separately deployable application of its own?</p>
339.  
340. <p>I believe it’s easier to approach this from the opposite
341. direction. Let’s take an example: A web-based email system. Let’s not
342. overcomplicate things and assume it’s traditional and offers the
343. minimal features you’d expect, such as logging in and out, maintaining
344. some user settings, creating messages (from scratch or by replying to
345. or forwarding an existing one), deleting messages, viewing your inbox,
346. moving messages into folders (that you can create, view and delete),
347. maintaining an address book, search for messages … I’m sure you get
348. the picture. At one extreme, we could absolutely build this as a
349. single application and ensure it’s built not as a single package, but
350. using a reasonable internal modularization strategy. We could decide
351. to write its core as a set of collaborating classes, maybe adhering to
352. the DDD approach (which would classify the classes according to the
353. role they play). Then we’d add the dependencies to the outside world,
354. such as the UI, the data storage, external systems (such as maybe
355. external mail handlers, LDAP directories, etc.), possibly using a
356. layered or hexagonal architecture.</p>
357.  
358. <p>The team(s) working on this application would need to synchronize very
359. tightly, as the whole thing is released at once. It will also be
360. scalad in an all-or-nothing fashion, and it will be down or up and
361. running completely, not partially. That may be perfectly fine! But
362. let’s just assume (again) you deem it’s not, and want to cut it apart
363. into separate parts that have their own life-cycle and are isolated
364. from each other.</p>
365.  
366. <p>How would you go about decomposing this into separate applications or
367. services? First of all, the login/logout stuff (the auth system) is
368. a good candidate, as is the user profile. They could go into one
369. service, but if we consider that the auth system has to maintain
370. passwords (or rather, password hashes), it makes sense in my view to
371. treat it differently from the rest. The emails and folders themselves
372. seem quite cohesive to me, though: You could separate them, but I
373. probably wouldn’t. If there are multiple ways to connect to the
374. outside world, say, via the Web interface, POP3, IMAP, and SMTP, I can
375. imagine each of those being their own service. Maybe I’d factor out
376. the storage of messages into its own service, one that doesn’t know
377. the difference between a document and an email. I think the address
378. book, including its data storage, its UI and its API seems like a
379. natural candidate to be separated from the rest.</p>
380.  
381. <p>But in all, I’d probably end up with a dozen, maybe twenty or thirty
382. services (or <em>self-contained systems</em>, as I prefer to call them). And
383. more importantly, I think that for any given interaction triggered by
384. some outside event – like e.g. a user clicking a button after entering
385. data into a form – I’d end up touching maybe 3-5 of them.</p>
386.  
387. <p>In other words, I think it’s not a goal to make your services as small
388. as possible. Doing so would mean you view the separation into
389. individual, stand-alone services as your <em>only</em> structuring
390. mechanism, while it should be only one of many.</p>
391. </description>
392.    </item>
393.    
394.    <item>
395.      <title>Just do it</title>
396.      <link>https://www.innoq.com/blog/st/2014/11/just-do-it/</link>
397.      <pubDate>Mon, 10 Nov 2014 20:20:00 +0100</pubDate>
398.      
399.      <guid>https://www.innoq.com/blog/st/2014/11/just-do-it/</guid>
400.      <description>&lt;p&gt;Three posts in quick succession: &lt;a href=&#34;http://scribbling.net/2014/10/16/short-form-blogging/&#34;&gt;This one&lt;/a&gt; by Gina Trapani, &lt;a
401. href="http://sixcolors.com/post/2014/10/bigger-than-a-tweet/">this one</a> by Jason Snell, and <a
402. 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>
403. </description>
404.    </item>
405.    
406.    <item>
407.      <title>Women in Tech</title>
408.      <link>https://www.innoq.com/blog/st/2014/08/women-in-tech/</link>
409.      <pubDate>Mon, 04 Aug 2014 18:13:00 +0100</pubDate>
410.      
411.      <guid>https://www.innoq.com/blog/st/2014/08/women-in-tech/</guid>
412.      <description>&lt;p&gt;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.&lt;/p&gt;
413.  
414. <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>
415.  
416. <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>
417.  
418. <ul>
419. <li>There is no inherent reason at all why men should be better at technical tasks than women (or vice versa).</li>
420. <li>The software community (or IT/tech industry, if you prefer) does not have a remotely reasonable share of women.</li>
421. <li>The reason for this is a complex mixture of
422. a) things that happen in our education system, very early in peoples’ lives, that make women pursue a different career
423. b) things that the tech industry does that make it unattractive for women
424. c) things the tech industry does that drive women who do enter it into leaving it again</li>
425. <li>Whatever the reasons may be, the effect is undoubtedly negative because
426. 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
427. b) a more diverse group is way more fun to work with and (if studies are to be believed) more productive</li>
428. <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>
429. </ul>
430.  
431. <p>Do you disagree with any of these?</p>
432. </description>
433.    </item>
434.    
435.    <item>
436.      <title>On Monoliths</title>
437.      <link>https://www.innoq.com/blog/st/2013/10/on-monoliths/</link>
438.      <pubDate>Tue, 22 Oct 2013 10:47:00 +0100</pubDate>
439.      
440.      <guid>https://www.innoq.com/blog/st/2013/10/on-monoliths/</guid>
441.      <description>&lt;p&gt;A while ago, I gave a talk at QCon about breaking up monoliths
442. (<a href="http://www.infoq.com/presentations/Breaking-the-Monolith" title="Breaking the Monolith">there’s a video up on InfoQ</a>), repeated it in a slightly improved version
443. at JavaZone (see
444. <a href="https://speakerdeck.com/stilkov/breaking-the-monolith-1">slides</a> and
445. <a href="http://vimeo.com/74354372">video</a>), and the topic continues to come
446. up in almost every consulting engagement and client workshop I’ve been
447. involved in since then. Like many of the topics I talk about, it’s
448. somewhat unfair that I get the positive feedback and people assume I
449. came up with the ideas all on my own: Most of stuff like this is the
450. result of collaboration, with my colleagues at <a href="http://www.innoq.com">innoQ</a> (see for
451. example
452. <a href="http://www.sigs-datacom.de/fachzeitschriften/objektspektrum/online-themenspecials/artikelansicht.html?tx_mwjournals_pi1%5Bpointer%5D=0&tx_mwjournals_pi1%5Bmode%5D=1&tx_mwjournals_pi1%5BshowUid%5D=7022">an article I wrote with Phillip Ghadir for ObjektSpektrum</a>
453. if you read German), as well as customer staff. But wherever it
454. originated, I found that it strikes a nerve with many developers and
455. architects, not only in big companies that conduct million-Euro
456. development projects, but also in smaller e-commerce companies and
457. even startups that have started to become successful.</p>
458.  
459. <p>The main idea is this (no surprise for almost everyone, I guess):
460. <em>Nobody</em> wants monoliths, i.e. big systems composed of hundreds of
461. thousands or millions of lines of code (in a language like Java) or
462. tens of thousands (e.g. in Ruby), yet everyone ends up having
463. them. And once you have one, you’re basically stuck with them: They’re
464. incredibly hard to maintain, extend, and modernize; yet they provide
465. value and can’t simply be replaced (something that many organizations
466. attempt but fail at, because it’s awfully hard to create something new
467. that is not only great in terms of architecture, but also can actually
468. function as a full replacement for all of the old system’s features.</p>
469.  
470. <p>So what’s the proposed remedy? To talk about that, we need to take a
471. step back and find out how we actually end up systems that are too big
472. in the first place. My theory is that the number one reason is <em>project
473. scope</em>.</p>
474.  
475. <p>When a project is started, there is an assumption that it’s the goal
476. of a project to create a single system. This typically goes
477. unquestioned, even though the people or person coming up with the
478. project boundaries often don’t decide this consciously. This is most
479. obvious if they’re non-technical people who make decisions on a budget
480. basis.</p>
481.  
482. <p>So the very first thing we should be doing as architects (or lead
483. developers if you don’t like the term) is to find out what it actually
484. is we should be building. Is it really a single system? If our task is
485. to replace an existing system with a new one, it’s very tempting to
486. just accept existing boundaries and go with them. If we’re
487. consolidating two systems, it’s equally tempting to view our scope as
488. the union of the predecessor systems’ scope. In the rare cases where
489. our task is to actually modularize something existing, it’s because of
490. business reasons (such as deregulation). Again, while it might seem
491. like a good idea to just accept the boundaries being suggested to us,
492. it’s not at all clear why this should be a good idea. After all,
493. if whoever came up with those boundaries is not an architect or
494. developer, what makes us think they made a good choice?</p>
495.  
496. <p>In my view, the most important thing to do, then, is to find out how
497. many systems we should be building in the first place. It may be a
498. single one, but it may also be two, five or a dozen (though probably
499. not more) – clearly, the decision should be made very consciously,
500. because whatever system boundaries you pick, you will likely be stuck
501. with them for a very long time.</p>
502.  
503. <p>As “system” is a term that can mean almost anything, I need to define
504. what I mean by it in this context. A system is an independent unit
505. that is developed according to its own rules, and only connected to
506. other systems in an unobstrusive fashion. A system, according to this
507. model, has its own database, business logic, and user interface; it’s
508. deployed separately. It’s likely developed by a different team than
509. other systems. It has its own life cycle, in terms of development as
510. well as deployment. It’s operated autonomously. It has its own test
511. suite. In basically every regard, it’s as different from all the other
512. systems as a piece of commercial off-the-shelf software would be. (In
513. fact, one of the systems may end up being a piece of standard
514. software.) Is that the same as the “Micro Services” idea? If you watch
515. James Lewis’s great talk
516. (<a href="http://vimeo.com/74452550">here’s a recording</a>, also done at
517. JavaZone; in fact his was scheduled directly after mine), you’ll find
518. a lot of similarities, but the major difference is probably the size
519. of each individual unit. But to me, seeing similar concepts appear in
520. different contexts is a very good sign.</p>
521.  
522. <p>It doesn’t really matter that much whether you get the number and
523. distribution right with the first attempt – in fact, you can
524. reasonably consider that to be highly improbable. But it’s one thing
525. to find out you should have built six or eight systems instead of seven,
526. i.e. get it wrong in one or two places, and a completely different one
527. to notice it should have been seven instead of one.</p>
528.  
529. <p>I’ve rambled on for long enough for a single post, so here’s a
530. preliminary conclusion: How many systems you build should be a very
531. conscious decision. It will affect the life of those tasked with
532. evolving and maintaining it for years to come.</p>
533. </description>
534.    </item>
535.    
536.    <item>
537.      <title>Harassed by Getty Images</title>
538.      <link>https://www.innoq.com/blog/st/2013/10/harassed-by-getty-images/</link>
539.      <pubDate>Mon, 07 Oct 2013 11:52:00 +0100</pubDate>
540.      
541.      <guid>https://www.innoq.com/blog/st/2013/10/harassed-by-getty-images/</guid>
542.      <description>&lt;p&gt;Ah, the joys of &amp;ldquo;Intellectual Property&amp;rdquo;. I&amp;rsquo;ve been a long-time fan of the wonderful demotivational posters offered by &lt;a href=&#34;http://www.despair.com&#34;&gt;despair.com&lt;/a&gt;. 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 &amp;ndash; on one occasion not only using a plain &lt;code&gt;&amp;lt;a&amp;gt;&lt;/code&gt;, but an &lt;code&gt;&amp;lt;img&amp;gt;&lt;/code&gt; element as well, embedding one of their images on this site (&lt;a href=&#34;https://www.innoq.com/blog/st/2006/01/demotivation.html&#34;&gt;this&lt;/a&gt; is the post minus the image). After all, why not send a little traffic to these fine folks?&lt;/p&gt;
543.  
544. <p>But obviously Despair uses stock photos – a perfect use case if there ever was one –, and the rights to the particularly cheesy ones apparently belong to Getty images. Now I’ve received a letter, first from their internal legal department, and – after explaining the misunderstanding on their part – now from their lawyer. In both cases, they insist that we need to license the image to use it.</p>
545.  
546. <p>As I didn’t copy the image of the poster, but only link to it, this seems entirely absurd to me – particularly if Despair properly licensed the image, which I’m quite sure of. (If at all, Despair might have more reason, but I can’t believe they’d be that unreasonable, purely out of their own interest.) But my guess is the legal trolls at Getty believe it won’t be worth the hassle to me. They’re wrong – I don’t believe they deserve a single cent of my (or the company’s) money. If you have any advice, or want to share some of your own experience with these people, please leave a comment.</p>
547. </description>
548.    </item>
549.    
550.    <item>
551.      <title>Keyboard Optimization</title>
552.      <link>https://www.innoq.com/blog/st/2013/06/keyboard-optimization/</link>
553.      <pubDate>Sun, 30 Jun 2013 21:19:00 +0100</pubDate>
554.      
555.      <guid>https://www.innoq.com/blog/st/2013/06/keyboard-optimization/</guid>
556.      <description>&lt;p&gt;For the last few months, I&amp;rsquo;ve been continuously tweaking my laptop
557. settings to optimize my typing speed and efficiency. Here are some of
558. the things I’ve learned, and some of the tools and approaches I’m
559. currently using.</p>
560.  
561. <ul>
562. <li><p>I finally took up “real” touch typing, i.e. using 10 fingers and a
563. classical system. For years I’d been quite satisfied, even a little
564. proud, of my awesome typing skillz, only to be shot down when I took
565. the first real speed typing test and found myself scoring a ridiculous 30-40
566. words per minute, the reason being mostly mistakes and the
567. “occasional” peeking if some not-so-common character came along. There
568. are a ton of tools for learning touch typing. The one I spent the most
569. time with is the excellent (and free) <a href='http://www.tipp10.com/en/index/'>Tipp10</a>, which is available in
570. both offline and online versions. There’s also the very nicely done
571. <a href='https://itunes.apple.com/en/app/keys/id526394170?mt=12'>Keys</a> if you’re on a Mac and have a US keyboard. If you like to have
572. some social interaction, both <a href='http://10fastfingers.com/'>10 Fast Fingers</a> and <a href='http://play.typeracer.com/'>Typeracer</a> are also
573. quite nice. Finally, for a programmer, <a href='http://typing.io/'>typing.io</a> is a fantastic resource.</p></li>
574.  
575. <li><p>I switched to a US keyboard layout a while ago. I don’t know why
576. I’d put this off for so long; while I originally started out using a
577. German keyboard layout (QWERTZ instead of QWERTY), I easily write half
578. of what I produce in English, so it wouldn’t have hurt to do this
579. earlier. The most important benefits are that almost all of the
580. characters required in programming languages are far easier to type
581. using a US keyboard and all of the keyboard shortcuts, particularly in
582. editors such as my favorite, Emacs, suddenly make a lot more
583. sense. Because I still type a lot of German texts and hated the
584. default input method for umlauts and the German “ß”, I installed <a
585. href='http://hci.rwth-aachen.de/USGermanKeyboard'>the great “USGerman” keyboard layout</a>, which allows me to use Option+a, u, o and s to
586. get the appropriate characters with a single combination. This has
587. turned out to be a very workable solution.</p></li>
588.  
589. <li><p>It also made me use Cmd for Meta in Emacs, which is both good and bad:
590. It’s good because when you use Emacs, you use Meta a lot; it’s bad,
591. because some of the keyboard shortcuts for moving around now need to
592. be done with Cmd (in Emacs) and Option (everywhere else), which can be
593. a bit annoying. Also, I ordered my new laptop with a German keyboard
594. layout by accident, which ended up being great because it means I now
595. have no chance to actually look at the keyboard for those special
596. characters anymore. (It also allowed me to turn the keyboard lighting
597. all the way down.)</p></li>
598.  
599. <li><p>Speaking of Emacs, I wanted to make sure I have the Emacs short
600. cuts available everywhere. This is actually the case to a large degree
601. by default on a Mac, but I wanted to be able to rely on combinations
602. such as Ctrl-M, Ctrl-H, Ctrl-I, etc. Enter the slightly ugly, stupidly
603. named, but incredibly powerful <a href='https://pqrs.org/macosx/keyremap4macbook/index.html.en'>KeyRemap4MacBook</a>, which allowed me to
604. ensure Emacs keys work everywhere. (I hear this is possible for vi
605. users, too.)</p></li>
606. </ul>
607.  
608. <p>Now I find myself not taking my fingers off home row very much, and I’m
609. comfortably moving along at 60-80 wpm. There’s a weird satisfaction in
610. this – I noticed that in a recent company-internal discussion, many
611. of my co-workers did not seem to see much of a point in taking up
612. touch-typing because they don’t see typing speed as the limiting
613. factor. One reason I might see this differenly is because I (sadly) don’t
614. program much these days, but produce a lot of prose instead. And there, at
615. least, I’m absolutely confident that not having your typing get in the
616. way is a huge asset.</p>
617. </description>
618.    </item>
619.    
620.    <item>
621.      <title>Why I like Schemaless Data Structures</title>
622.      <link>https://www.innoq.com/blog/st/2013/01/why-i-like-schemaless-data-structures/</link>
623.      <pubDate>Mon, 07 Jan 2013 23:00:00 +0100</pubDate>
624.      
625.      <guid>https://www.innoq.com/blog/st/2013/01/why-i-like-schemaless-data-structures/</guid>
626.      <description>&lt;p&gt;Martin Fowler has written an infodeck (which is actually a nice format for these kinds of things) &lt;a href=&#39;http://martinfowler.com/articles/schemaless/&#39;&gt;on schemaless databases and in-memory structures&lt;/a&gt;. 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&amp;rsquo;s the reason why I don&amp;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:&lt;/p&gt;
627.  
628. <p>First, a major effect of using “schemaless”, simple data structures is loose® 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’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>
629.  
630. <pre><code>;; "projects" is a Clojure set containing three maps
631. (def projects #{
632.                {:id "1",
633.                 :kind :time-material,
634.                 :description "Consulting for BigCo",
635.                 :budget 25000,
636.                 :team [:joe, :chuck, :james]}
637.                {:id "2",
638.                 :kind :fixed-price,
639.                 :description "Development for Startup",
640.                 :budget 100000,
641.                 :team [:john, :chuck, :james, :bill]}
642.                {:id "3",
643.                 :kind :fixed-price,
644.                 :description "Clojure Training",
645.                 :budget 3000,
646.                 :team [:joe, :john]}})
647.  
648. ;; all-members returns all team members in all projects
649. (defn all-members
650.  [projects]
651.  (reduce conj #{} (flatten (map :team projects))))
652.  
653. ;; yields #{:chuck :joe :james :john :bill}
654. </code></pre>
655.  
656. <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>
657.  
658. <p>More importantly, it’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’d be using remotely (in fact there’s a very nice mapping between a nested Clojure, Ruby or Python data structure and e.g. JSON.)</p>
659.  
660. <p>Some languages, such as Clojure, take this to an extreme: Almost everywhere you’d create a new class in an OO language, you’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 “normal” Java classes, too.) Some languages are somewhere in the middle, as shown by the Ruby code in Martin’s example. But I find it not very useful to favor one style over the other by default, unless you consider the language you’re using.</p>
661.  
662. <p>Secondly, the use of custom-built data structures – and that’s what a schema boils down to if viewed from a programming language standpoint – always means additional code. You might consider this irrelevant, but it’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>
663.  
664. <p>In summary, I think of Martin’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 – coupling and verbosity – are worth considering when you need to decide which approach to use.</p>
665. </description>
666.    </item>
667.    
668.    <item>
669.      <title>New languages</title>
670.      <link>https://www.innoq.com/blog/st/2012/12/new-languages/</link>
671.      <pubDate>Sat, 22 Dec 2012 15:00:00 +0100</pubDate>
672.      
673.      <guid>https://www.innoq.com/blog/st/2012/12/new-languages/</guid>
674.      <description>&lt;p&gt;Being a programming language geek, I typically try to use the
675. Christmas vacation to learn (or rather, play with) a programming
676. language I don’t know. This year, I find this very hard, as there are
677. so many interesting languages one could spend time with. Some I have
678. considered are:</p>
679.  
680. <ul>
681. <li>Go: I was thoroughly unimpressed with this language when it came
682. out, and I still fail to see a lot of interesting stuff in it. But
683. I’ve heard many people I respect say only good things about their
684. experience with it, so maybe I should reconsider.</li>
685. <li>Rust: At first glance, this seems to be a very nicely designed
686. language (and it has a really excellent tutorial). Even though its
687. language features are very advanced, it seems to be intended for
688. low-level use cases (that I mostly don’t have).</li>
689. <li>Fantom: Seems to be  interesting, too; I remember I looked at it
690. a long time ago, but never in depth.</li>
691. </ul>
692.  
693. <p>What do you think? What else is worth a look?</p>
694. </description>
695.    </item>
696.    
697.  </channel>
698. </rss>

If you would like to create a banner that links to this page (i.e. this validation result), do the following:

1. Download the "valid RSS" banner.

2. Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)

3. Add this HTML to your page (change the image src attribute if necessary):

   <a href="http://www.feedvalidator.org/check.cgi?url=http%3A//www.innoq.com/blog/st/atom.xml"><img src="valid-rss-rogers.png" alt="[Valid RSS]" title="Validate my RSS feed" /></a>

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

Home · About · News · Docs · Terms