Pssst - this is a RSS only post.
Please keep it secret. Read more about RSS Club.
For a while I’ve been thinking of capturing thoughts / experiences regularly.
You will find thoughts related to my work, my passions, and my life.
Last week I joined a long running project.
Couple of thoughts from this:
Most of challenges are related to organization, and processes
It’s really hard to get in context when no having access to code, tools, information.
it’s like watching a twitch stream for 8-9 hours per day
it’s like coding by looking at the key hole
This team is awesome. They are skilled, and easy to work with.
The tools… Locked down, super limited. Not ideal.
I’m getting tired of getting all my tools imposed on me. There is a context to it, but it does not make it much easier to digest.
Here I’m talking primarily about my hope to use Linux, and Emacs at work.
This is harder when working for a consulting firm, where there are many layers of decision makers, and it’s a constant beginning every x months.
The Object Mother pattern is great as a way to create your test fixture. Especially for complex domain objects.
I’ve successfully implemented it in the past by combining it with the builder pattern. It made it really nice and fluent.
This week, I’ve seen it implemented as an abstract factory. I think the builder approach works better.
This library manipulates byte code and inject changes in your Java classes. Some features it brings are related to created accessors, builders, etc…
Couple of things overlooked when including lombok in a tech stack:
# of active contributors (roughly 4)
# of bugs (732 open bugs)
risk of breaking in the future manipulating byte-code is and will break in many major revisions
conflict with other libraries and the JVM runtime in some scenarios, manipulating byte-code can impact dynamic proxies, transactions, AOP matchers, etc.. I experienced some issues in the past between Lombok and H2 DB.
troubleshooting since lombok is byte-code without actual source code, it’s harder to troubleshoot issues.
This is quite a long list of risks for a simple set of features.
There are other alternatives to lombok:
for getters / setters: just use the IDE to generate your accessors
builder: snippets to generate actual builders. some IDEs does it. or get a builder generator that creates java code in target/generated-sources
At this point, you may have guessed I never use lombok unless it’s already in our client’s code.
I’m tired of OO, statically typed languages and tools I need to use at work. (reasons may be explained in later posts)
My career goals are to continue building awesome piece of software using the tools and language I like.
This week has been quite active in this area:
setting up mail / gpg with nix home-manager
started to plan how to setup Emacs as a replacement for IntelliJ for Java dev started playing with lsp-mode
Refactoring of the way I deal with my git repositories setup group of repos: private, public, contrib, and others.
These are all my public repositories where I’m the only contributor.
New strategy is:
origin will be pointing to sr.ht
mirror will be pointing to github
setup myrepo to push to both remotes
no additional remotes (no upstream)
stuff not ready to share
New strategy is:
origin points to my own private git server on my nas
no other remotes
checks to make sure remotes dont change or point to public repositories
I’ve been renovating my old house for many years. I usually do everything myself.
This week, I’m planning:
finish some plastering / painting touch-ups.
start planning the construction of my new office.