Feb 28, 2015 •

So what is continuous integration, at the very high level it’s about hey is
the code in a good state, no matter by how many people code is being updated,
how often code is being changed or of how many building blocks project consists of.
When you start working on a feature you’re gonna branch of mainline and start
introducing changes. At some point when you find things are broken now you have
to spend time to see if it’s because of your changes or project was already in
a bad state. And when you find out that it was already in a bad state you
would want to start tracing. A who introduced the breaking changes and B when.
So to avoid the head each and frustration what you really want to know is
if project is in a good state before you even start working on it.
One option would be to compile the code before you start changing it.
But if code compiles is it enough? Oh you you also wanna know if unit tests are
passing. But is this enough? Check for compiler warnings? Style violations?
Code coverage? What if you run code coverage and it shows that it’s 85%,
does it mean everything is good, what if code coverage was 95% last week and
code without proper code coverage got committed and code coverage dropped
(do you remember what code coverage was last week, can you even find
out without going back in commits and running coverage reports on those commits.) are you sure
you want to introduce your changes on top of those changes?
Let’s make it even more complex, what if the project consists of many other
projects and the project you’re working on brings all those dependencies
tougher. Maybe you should checkout all those dependency projects
and see if those are in a good state also.
Let’s make it even more complex, what if the project isn’t just set of
projects that get bundled into one big project.
What if the whole code base consists of many micro services that talk to each other
via some form of PRC. OK maybe you can manage to do all this to know if code is
in a good state before you introduce your changes what about the point B I
brought earlier about when code broke, because longer it was in that states
longer it’s gonna take to trace the breaking change and longer to fix.
Can you go and check every single project every time someone makes a commit
to make sure that commit is good? Well actually you can, you just need a
build server. So all those points I was bringing was about whatever your
integration is it should be continuous and it’s continuous if it runs after
somebody changes something (or maybe before is a better option?☺ I’ll get
to this later.)

Feb 8, 2015 •

If you work in an organization or doing your personal project sooner or latter
you’re gonna need an artifact server. And few reasons this would be you want to
host your build artifacts but not make those available to the public, you want
to have a proxy server to use when you download your artifacts, this is
particularly
helpful when you have more than one person working on the project or you simply
have some jars that aren’t in maven central or other public repos and you want
to host those so you can list them as dependencies from your build tool.

Jan 29, 2015 •

Some people prefer text editors with graphical interface, some can’t live
without an IDE, some like web based editors. One nice thing about those is that
those applications or the web browser is doing spell checking for you and you
see what you misspell as you go. I prefer Vim for most part and it being a
command line application you think you’ll be out of options there but no.
Vim has a nice built in spell checker.

Jan 25, 2015 •

As most technology guys I’m also working on different technologies, playing
with new stuff, facing some challenges that I end up solving.
Always wanted to blog about what I’m working on since if it interests me then
others can also find it helpful or interesting.