25 years of experience in the field of industrial software engineering, 15 years of experience as technical team leader on complex projects
kotlin, java/j2ee, c++, bash/perl, gnu/linux, sql, javascript, html5/css3, docker
25 years of experience in the field of industrial software engineering, 15 years of experience as technical team leader on complex projects
kotlin, java/j2ee, c++, bash/perl, gnu/linux, sql, javascript, html5/css3, docker
One of the greatest nuisances of the software world is trends. It seems like often CTOs will build their company infrastructure using trendy components without questioning their real pertinence.
A typical example of this tendency, in the Java world, is the popularity of the dreadful Spring+Hibernate duo. I'm pretty sure those frameworks have been coded with talent and contain several good ideas, but are they even needed? Today, every database engine has a mature caching layer. Is Hibernate memory persistence (with its complex handling of joins and freshness) really worth the extra complexity compared to a simple ORM layer? Does one need to adopt all of Spring inherent complication to get the benefit of dependency injection and loose coupling, which a bare J2EE setup doesn't prevent? I'd often answer no, even for big companies.
Whereas frameworks, with their top-down philosophy, appear to be reassuring choices at first glance, the bottom-up approach offers many advantages. Frameworks impose enormous constraints on underlying components, architecture flexibility and transparency, design choices, customization, and learning curve. The J2EE norm is all but a low-level norm which complexity should be hidden. It's an elegant and very clean architectural standard by itself.
In a nutshell: frameworks are like dinosaurs. Tools are like small mammals.
Let's wait for the next meteorite.
I have been living in Marseille (Southeast of France) since 2008, and am often staying in Paris for business or leisure.
I practise rock climbing in the Calanques, one of the main reasons why I chose to live in the South.I'm a big fan of the game of Go, and am volunteering to my local Go club and some system administration on the French Go Federation server where we host about a hundred club sites.
I have been practicing improvisational theatre for more than four years now, within a group which is starting to give regular public spectacles.
I contribute to some open source projects, mainly Apache Velocity (a template engine), Modality (an ORM), and a few others.
Some of my personal projects are visible here and there.
The first and main point about open source software is that it made the productivity of individual developers really explode. So economically speaking, it’s a great success. Add to this that using established open source software is a guaranty of code quality, security, customizability, reactivity, autonomy, community presence and low costs ; and you really wonder why some people still want to pay for less quality. Habits, maybe.
Now, when it comes to your code: should it be opened or not? Well, not necessarily. You do not want to expose your goose that lays golden eggs. Nor do you want to show everyone your quick and dirty code that fulfills your current needs. Note that going full open source is sometimes a viable path if it makes sense to be paid for services, exploitation rights or extra features, and you’ll cut many testing, debugging, commercial and marketing costs. More often, a good candidate to open sourcing will be a side module, not specific to your business, sufficiently complex and/or generic that there is more sense in letting a community maintain it than spending the resources yourself to keep it afloat.
And here, we are specifically talking about code. But there is more to it. Next to open source lies open data, open electronics, open governance... Today you can already find open source mobiles, open source cars, but not yet any open source dishwasher, alas.
As a regular remote worker, I tend to think that it is pretty important to physically meet your coworkers from time to time, especially at the beginning of a project. But, once trust has been built, remote work can reveal itself more motivating and efficient than on site work, provided to ensure contact with some kind of team chat like Slack, Discord, Mattermost, etc.