-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathindex.xml
303 lines (250 loc) · 21.4 KB
/
index.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>A guy with 'Ego' in his name</title>
<link>https://bsideup.github.io/</link>
<description>Recent content on A guy with 'Ego' in his name</description>
<generator>Hugo -- gohugo.io</generator>
<language>en</language>
<lastBuildDate>Tue, 24 Dec 2024 13:43:58 -0700</lastBuildDate>
<atom:link href="https://bsideup.github.io/index.xml" rel="self" type="application/rss+xml" />
<item>
<title>NixOS on Raspberry Pi: The Good, the Bad and "the Linux way"</title>
<link>https://bsideup.github.io/posts/nixos_rpi/</link>
<pubDate>Tue, 24 Dec 2024 13:43:58 -0700</pubDate>
<guid>https://bsideup.github.io/posts/nixos_rpi/</guid>
<description>Gran Torino (Film) © 2008 Warner Bros. Pictures
Disclaimer: this is not a tutorial, but a story of me trying the new hype thing that I am probably too old for 😀
I have a confession to start this article with: I have never enjoyed &ldquo;the Linux way&rdquo; of doing things:
&ldquo;Everything at once&rdquo; package updates via distributives Having a strong allergy to binaries Piping like a 19 y.</description>
</item>
<item>
<title>Trying Rootless Docker with Testcontainers</title>
<link>https://bsideup.github.io/posts/rootless_docker/</link>
<pubDate>Fri, 10 Jul 2020 14:22:31 +0200</pubDate>
<guid>https://bsideup.github.io/posts/rootless_docker/</guid>
<description>Rootless Docker is one of the most exciting recent changes in the Docker ecosystem.
It allows you to run the same good old Docker but without having to obtain root privileges on the machine.
Installing Rootless Docker on a fresh VM Although you can run Rootless Docker-in-Docker, I wanted to try it on a fresh environment.
A few seconds later, I had an Ubuntu VM running on Oracle Cloud to play with:</description>
</item>
<item>
<title>Daily Reactive: Context loss detection in Project Reactor</title>
<link>https://bsideup.github.io/posts/daily_reactive/context_loss_detection/</link>
<pubDate>Wed, 10 Jun 2020 10:22:38 +0200</pubDate>
<guid>https://bsideup.github.io/posts/daily_reactive/context_loss_detection/</guid>
<description>This post is a part of the &ldquo;Daily Reactive&rdquo; series of short posts about common situations with Project Reactor and Reactive Programming.
One of the unique features of Project Reactor is the Context support. It allows you to associate an immutable context (represented by key/value pairs) and pass it to the upstream subscribers:
public Flux&lt;Item&gt; getItems() { return Flux.deferWithContext(context -&gt; { String userId = context.get(&#34;userId&#34;); Publisher&lt;Item&gt; items = fetchItemsByUserId(userId); return items; }); } public void streamItems() { getItems().</description>
</item>
<item>
<title>Human-friendly Domains with Knative</title>
<link>https://bsideup.github.io/posts/knative_custom_domains/</link>
<pubDate>Mon, 06 Apr 2020 15:34:02 +0200</pubDate>
<guid>https://bsideup.github.io/posts/knative_custom_domains/</guid>
<description>Introduction Recently, I started playing with Kubernetes and Knative. The trigger was the credits I received to play with Oracle Cloud. I did not know how to use them and on which services (Java is the only Oracle&rsquo;s product I use :D), so I googled &ldquo;oracle cloud kubernetes&rdquo; and 15 minutes later I had a running cluster to play with. Nice!
After installing Knative (k apply -f FTW!) and Gloo as a gateway, I decided to move one of my pet projects to this cluster, just to get the feeling of what it takes to run a few services on it.</description>
</item>
<item>
<title>Writing TCKs with JUnit Jupiter's Dynamic Tests</title>
<link>https://bsideup.github.io/posts/tcks_with_jupiter_and_dynamic_tests/</link>
<pubDate>Mon, 16 Mar 2020 16:25:49 +0100</pubDate>
<guid>https://bsideup.github.io/posts/tcks_with_jupiter_and_dynamic_tests/</guid>
<description>When you develop a library that provides some abstraction, or write a spec, it is a good practice to include a TCK (Technology Compatibility Kit) that the implementers can use to verify the behavior of their implementation and how well it matches the spec.
You may find various TCKs out there, e.g. the Reactive Streams TCK.
I just need something to test Let&rsquo;s start with a simple example first. Consider we have the following contract defined:</description>
</item>
<item>
<title>Daily Reactive: Let's talk about ThreadLocals.</title>
<link>https://bsideup.github.io/posts/daily_reactive/thread_locals/</link>
<pubDate>Wed, 12 Feb 2020 13:44:18 +0100</pubDate>
<guid>https://bsideup.github.io/posts/daily_reactive/thread_locals/</guid>
<description>This post is a part of the &ldquo;Daily Reactive&rdquo; series of short posts about common situations with Project Reactor and Reactive Programming.
ThreadLocals is one of the most common pain points topics nobody wants to talk about in the reactive world. Unlike in synchronous programming, asynchronous programming makes them hard to use due to a lot of context switching and thread pooling.
Consider the following example:
static final ThreadLocal&lt;String&gt; USER_ID = new ThreadLocal&lt;&gt;(); @Test public void testThreadLocals() { USER_ID.</description>
</item>
<item>
<title>Local development with Testcontainers</title>
<link>https://bsideup.github.io/posts/local_development_with_testcontainers/</link>
<pubDate>Tue, 11 Feb 2020 13:29:47 +0100</pubDate>
<guid>https://bsideup.github.io/posts/local_development_with_testcontainers/</guid>
<description>Testcontainers is a very helpful library when it comes to integration testing.
One of the main benefits of it is that you can code your &ldquo;dependencies&rdquo; (like databases, brokers, cloud mocks, and other I/O sources) and start them with Docker from your tests - no need to run any additional command like docker-compose up or anything!
But sometimes it is still useful to start your application and play with it.</description>
</item>
<item>
<title>E2E test your Spring Boot 2.3.0 apps with Testcontainers</title>
<link>https://bsideup.github.io/posts/spring_boot_in_container/</link>
<pubDate>Thu, 30 Jan 2020 14:43:14 +0100</pubDate>
<guid>https://bsideup.github.io/posts/spring_boot_in_container/</guid>
<description>Spring Boot 2.3.0.M1 comes with a number of great features. I find one of them especially interesting - now you can build layered Docker images using Cloud Native Buildpacks!
It is a very fast way of building Docker images compared to the Dockerfile approach thanks to Buildpacks.
It is so fast that we can use it&hellip; to build, start and test our service as a Docker container (with Testcontainers, of course!</description>
</item>
<item>
<title>Why you should never use fixed ports in your Testcontainers tests</title>
<link>https://bsideup.github.io/posts/testcontainers_fixed_ports/</link>
<pubDate>Mon, 27 Jan 2020 12:23:19 +0100</pubDate>
<guid>https://bsideup.github.io/posts/testcontainers_fixed_ports/</guid>
<description>I admit it - people are used to static ports. Web server? port 80! Redis? 6379! Java app? 8080!
But let&rsquo;s be honest, the following also looks painfully familiar:
Bind for 0.0.0.0:80 failed: port is already allocated. But there is more - localhost is the king!
There was some disturbance back in the days of docker-machine (magical 192.168.99.100, anyone? Heck, I even wrote a tool that auto-forwards ports to localhost), but people really think everything they start on from their machine should be on localhost.</description>
</item>
<item>
<title>Daily Reactive: Pagination</title>
<link>https://bsideup.github.io/posts/daily_reactive/pagination/</link>
<pubDate>Fri, 20 Dec 2019 14:50:02 +0100</pubDate>
<guid>https://bsideup.github.io/posts/daily_reactive/pagination/</guid>
<description>This post is a part of the &ldquo;Daily Reactive&rdquo; series of short posts about common situations with Project Reactor and Reactive Programming.
In one of the previous Daily Reactive posts we talked about the polling.
Today we will focus on an interesting example of the polling: Pagination.
Example Let&rsquo;s say we have the following API:
interface Page extends Iterable&lt;Item&gt; { Optional&lt;String&gt; nextPageId(); } interface Client { CompletionStage&lt;Page&gt; fetchPage(@Nullable String pageId); } As you can see, each fetchPage will get a page (where pageId == null means &ldquo;the first page&rdquo;).</description>
</item>
<item>
<title>Daily Reactive: Splitting a stream</title>
<link>https://bsideup.github.io/posts/daily_reactive/split/</link>
<pubDate>Thu, 19 Dec 2019 15:18:57 +0100</pubDate>
<guid>https://bsideup.github.io/posts/daily_reactive/split/</guid>
<description>This post is a part of the &ldquo;Daily Reactive&rdquo; series of short posts about common situations with Project Reactor and Reactive Programming.
Although it is not common, sometimes there is a need to split a Flux into a few. And one has to be careful to do it correctly!
Let&rsquo;s say we have a stream of persons and we want to return a Tuple of names and ids:</description>
</item>
<item>
<title>Daily Reactive: Pollable sources</title>
<link>https://bsideup.github.io/posts/daily_reactive/polling/</link>
<pubDate>Tue, 10 Dec 2019 12:51:29 +0100</pubDate>
<guid>https://bsideup.github.io/posts/daily_reactive/polling/</guid>
<description>This post is a part of the &ldquo;Daily Reactive&rdquo; series of short posts about common situations with Project Reactor and Reactive Programming.
Although streaming sources are very efficient with Reactive Streams, there are still many poll-based APIs. Kafka/Pulsar, REST, SQS/PubSub&hellip; You name it!
Let&rsquo;s say we have the following blocking legacy API provided by the database:
// SDK-provided class class Client { public Item poll() { // ... } } // and then: while (true) { var item = client.</description>
</item>
<item>
<title>Daily Reactive: Where is my exception?!</title>
<link>https://bsideup.github.io/posts/daily_reactive/where_is_my_exception/</link>
<pubDate>Mon, 09 Dec 2019 14:42:17 +0100</pubDate>
<guid>https://bsideup.github.io/posts/daily_reactive/where_is_my_exception/</guid>
<description>This post is a part of the &ldquo;Daily Reactive&rdquo; series of short posts about common situations with Project Reactor and Reactive Programming.
Exceptions For Flow Contol? Throwing an error is a very easy way of terminating the processing. Consider the following example:
public Mono&lt;Void&gt; sendRequest() { return doSendAndReceiveResponse() .doOnNext(buffer -&gt; { throw new StopProcessingException(buffer); }) .onErrorResume(StopProcessingException.class, e -&gt; { ResourceUtils.releaseResource(e.getBuffer()); return Mono.empty(); }) .then(); } Here, if we receive a response from the call, we throw an error (to cancel the flow, because error is a terminating signal and it will cancel the processing), and later we handle the error with onErrorResume in which we release the buffer.</description>
</item>
<item>
<title>Daily Reactive: Hello world!</title>
<link>https://bsideup.github.io/posts/daily_reactive/hello_world/</link>
<pubDate>Mon, 09 Dec 2019 13:42:17 +0100</pubDate>
<guid>https://bsideup.github.io/posts/daily_reactive/hello_world/</guid>
<description>&ldquo;Daily Reactive&rdquo; is a series of posts about Reactive Programming and Project Reactor.
The posts are inspired by some real world situations observed in Project Reactor&rsquo;s Gitter, or from working with the community, or even from the bug reports :)
Learn from others and avoid the most common pitfalls!
ℹ️ You can subscribe to the &ldquo;Daily Reactive&rdquo; only by using this RSS link.
</description>
</item>
<item>
<title>Zero-dependency Jackson entities with custom annotations</title>
<link>https://bsideup.github.io/posts/custom_jackson_annotations/</link>
<pubDate>Fri, 22 Nov 2019 08:13:08 +0100</pubDate>
<guid>https://bsideup.github.io/posts/custom_jackson_annotations/</guid>
<description>Jackson is a great library for working with JSON.
However, it is a bit too heavyweight to have it as a public dependency of your API. Especially if you&rsquo;re working on an Open Source library.
While refactoring docker-java, I got a challenge:
There are two modules: api and core api module (unlike core) should not have any dependency core can be shaded, which means that we cannot use provided scope for Jackson&rsquo;s annotations in api The entities in api have Jackson annotations like @JsonProperty, @JsonIgnore, @Creator and others Some entities require custom (de-)serialization If not 4, everything would be so easy.</description>
</item>
<item>
<title>Use Java 13 syntax in GraalVM with Jabel</title>
<link>https://bsideup.github.io/posts/graalvm_with_jabel/</link>
<pubDate>Wed, 04 Sep 2019 19:22:31 +0200</pubDate>
<guid>https://bsideup.github.io/posts/graalvm_with_jabel/</guid>
<description>GraalVM&rsquo;s native-image is great, but (at least at the time this post was published) it only supports Java 8.
Since Java 8, we got new language features like var, switch expressions, Milling of Project Coin and others.
But, if we want to use these features, Java compiler leaves no option other than producing Java 12+ bytecode, even tho they don&rsquo;t need it and can be compiled to Java 8.</description>
</item>
<item>
<title>Re-running flaky tests in Gradle</title>
<link>https://bsideup.github.io/posts/gradle_flaky_tests/</link>
<pubDate>Tue, 09 Jul 2019 10:32:12 +0200</pubDate>
<guid>https://bsideup.github.io/posts/gradle_flaky_tests/</guid>
<description>The world is not perfect, so are the tests, and one day you will get&hellip; a flaky test 😱
Flaky&hellip; what? As per Nebojša Stričević:
An essential property of an automated test and the entire test suite is its determinism. This means that a test should always have the same result when the tested code doesn’t change. A test that fails randomly is commonly called a flaky test.</description>
</item>
<item>
<title>Dependency Management in Gradle</title>
<link>https://bsideup.github.io/posts/gradle_dependency_management/</link>
<pubDate>Fri, 28 Jun 2019 14:02:22 +0200</pubDate>
<guid>https://bsideup.github.io/posts/gradle_dependency_management/</guid>
<description>There is one super popular thing I never did/do in my Gradle projects:
ext { lib_version = &#34;1.2.3&#34; } dependencies { compile &#34;org.corp:lib:$lib_version&#34; } Why not? I know that this approach was/is popular among Maven projects.
But I always preferred the dependencyManagement section of a parent POM because&hellip; it is standartized.
When you switch between projects and want to change a version of dependency, you know where you look at.</description>
</item>
<item>
<title>Detecting blocking calls in Akka with BlockHound</title>
<link>https://bsideup.github.io/posts/blockhound_with_akka/</link>
<pubDate>Tue, 28 May 2019 18:12:32 +0200</pubDate>
<guid>https://bsideup.github.io/posts/blockhound_with_akka/</guid>
<description>Asynchronous and non-blocking programming in JVM can provide very impressive performance results. Unlike the more classical blocking model, it runs on just a few threads from a pool. But, to keep it performant, you must ensure that you are not blocking these threads.
Just imagine having 4 threads in total, and blocking one of them for 100 milliseconds?
But how do you &ldquo;protect&rdquo; your application from the blocking calls?</description>
</item>
<item>
<title>The sad state of extension methods in the JVM ecosystem</title>
<link>https://bsideup.github.io/posts/jvm_extension_methods/</link>
<pubDate>Tue, 07 May 2019 17:37:23 +0200</pubDate>
<guid>https://bsideup.github.io/posts/jvm_extension_methods/</guid>
<description>Most of my time I write Java code. It isn&rsquo;t perfect, yet I find it good enough as my primary language. But sometimes I dream about the future of Java.
Given the latest activities around the Java language design (See Project Amber), the future looks brighter JEP-by-JEP, but one feature I really miss which isn&rsquo;t discussed by Amber is&hellip; Extension methods.
The problem Java language was heavily influenced by the OOP design.</description>
</item>
<item>
<title>How to locally debug containers started by Testcontainers</title>
<link>https://bsideup.github.io/posts/debugging_containers/</link>
<pubDate>Mon, 08 Apr 2019 15:52:05 +0200</pubDate>
<guid>https://bsideup.github.io/posts/debugging_containers/</guid>
<description>One of the best things Docker gave us was the port randomization. You no longer have to care about possible conflicts, especially on CI environments.
But it also created a big confusion for many users who got used to Redis listening on port 6379, or the Java debugger on 5005. Many tools are not container aware and expect things on static ports.
Well, we can&rsquo;t change the whole world (yet), but maybe there is something we can do for the Testcontainers users?</description>
</item>
<item>
<title>The Builder pattern vs Java syntax</title>
<link>https://bsideup.github.io/posts/builders_vs_java/</link>
<pubDate>Thu, 31 Jan 2019 13:29:11 +0100</pubDate>
<guid>https://bsideup.github.io/posts/builders_vs_java/</guid>
<description>The Builder pattern is one of the most popular patterns in Java.
It is simple, helps to keep objects immutable, and can be generated with tools like Project Lombok&rsquo;s @Builder or Immutables, to name a few.
Example of a fluent variant of the pattern:
public class User { private final String firstName; private final String lastName; User(String firstName, String lastName) { this.firstName = firstName; this.lastName = lastName; } public static Builder builder() { return new Builder(); } public static class Builder { String firstName; String lastName; Builder firstName(String value) { this.</description>
</item>
<item>
<title>My favourite GitHub bots</title>
<link>https://bsideup.github.io/posts/github_bots/</link>
<pubDate>Wed, 23 Jan 2019 13:58:43 +0100</pubDate>
<guid>https://bsideup.github.io/posts/github_bots/</guid>
<description>Year 2018 was an eye-opening year for me as an OSS project maintainer. The reason is due to the emerge of GitHub bots.
Maintaining a project on GitHub could be a challenging task, especially when the project becomes popular. Issue management, releases, follow-ups, dependency management, oh my!
But, as most of the developers, we&rsquo;re lazy enough and spend time automating things.
Dependabot https://github.com/apps/dependabot
There are many nice bots, but Dependabot is a real &ldquo;Good Boy Bot&rdquo;!</description>
</item>
<item>
<title>Easy Java delegates with Lombok</title>
<link>https://bsideup.github.io/posts/easy_java_delegates/</link>
<pubDate>Fri, 04 Jan 2019 15:17:30 +0100</pubDate>
<guid>https://bsideup.github.io/posts/easy_java_delegates/</guid>
<description>Ever wanted to override a method of an object instance in Java?
Let&rsquo;s say you want to implement a custom Scheduler hook for Project Reactor. You start with Schedulers.addExecutorServiceDecorator, implement a BiFunction accepting Scheduler&rsquo;s instance and ScheduledExecutorService and you need to return another ScheduledExecutorService instance where schedule* methods wrapped with your code.
A straightforward approach would be to create a new class, implement all methods of ScheduledExecutorService interface, and delegate most of them to the instance of ScheduledExecutorService we received as an argument.</description>
</item>
<item>
<title>JNI cross-compilation with Docker</title>
<link>https://bsideup.github.io/posts/jni-cross-compilation/</link>
<pubDate>Wed, 26 Dec 2018 17:56:42 +0100</pubDate>
<guid>https://bsideup.github.io/posts/jni-cross-compilation/</guid>
<description>As a JVM guy, I got used to &ldquo;write once, run everywhere&rdquo; paradigm. But recently I got an interesting challenge to solve.
I was working on a debugging tool for Project Reactor and part of it is implemented as a native library for Java, using JNI technology.
I did some C++ in the past but never thought how hard is it, to cross-compile a library for 3 major platforms (Windows, Linux and Mac), both locally and on CI environment (from where we perform the releases).</description>
</item>
</channel>
</rss>