Have you ever wondered what your application is made of? From which libraries? Have you ever seen their source code? Every time I looked at the dependency graph, I realized that we actually have zero control over it. Millions of lines of library code. What is in all these libraries? Is there anything “interesting” inside? Indeed, sometimes you can find some stuff inside. In order to fuel your inner paranoia, we recommend reading A story about how I’m harvesting credit card numbers and passwords from your site.
Link: Useful webinars from ThoughtWorks
ThoughtWorks hosts webinars on technical and the variety of other topics at least once a month. If you want to stay up-to-date with rapidly changing technologies, I strongly recommend you to check out our ThoughtWorks webinar.
It’s not uncommon to see Neil Ford or Martin Fowler on there with their talks and the latest research.
One of the recent talks was my talk about the different ways to organize the code. Starting from MVC as an architectural pattern, or rather an anti-pattern, and ending with Clean Architecture by Uncle Bob.
Do’s and Don’ts in Gatling
Recently, I spent a decent amount of time searching for a suitable load testing tool for a work project. Previously, we used JMeter, but it is quite difficult to write custom logic with it, which sometimes happens during load tests (preparing data in a tricky way, etc.). For this purpose, I turned to the Internet for info. We selected several options and finally settled on a tool called Gatling. Here are its main features:
- Knows how to “shoot at a target”
- Builds detailed reports
- Draws beautiful graphics
- Easily integrates into assembly
- Sufficiently rich and useful DSL (although based on Scala)
- It’s still a code (it will be an advantage for those who are tired of programming in XML)
We will not dwell on the features, you can study them yourself on the website of the maintainer. Let’s better go through the issues we faced in the process of working with it.
Sharing registries in financial systems
In this post, I would like to talk about a different kind of intersystem interaction. In the previous post we discussed how to avoid problems when connecting to external services, and today we will talk about a specific to some industries way of exchanging information, namely file sharing.
A little bit on Content Discovery
A couple of thoughts on a phenomenon such as content discovery. Once again I came across such a problem in one of the projects and decided to write about it. The post will be useless to those who are aware of how a security audit is conducted. However, for me, as a software developer, this once became a revelation. In information security, content discovery refers to the technique of searching for hidden resources, mainly in web applications.
I first encountered this phenomenon several years ago, when friends contacted me and said that their clients began to disappear. It was a small company. They had a sales department and a small one-page website where potential customers would leave their phone numbers. Then the sales managers called back to the customer and made deals. So, from a certain point on, customers who came to the site were processed by competitors before the manager had even a chance to call them.
At first, employees were the main suspects. Then I decided to take a look at the source code of the site. It turned out that the URL /clients (I don’t remember exactly) without any authentication was available to anyone for a few hours, showing the list of customers, who submitted the request. This URL was being twitched by the CRM and the new customers were being added to its database.
At that time, it wasn’t clear to me how to locate this path on the site, because it did not appear anywhere – neither in sitemap.xml nor in robots.txt or anywhere else. I did not know anything about content discovery, so I gave it a thought and eventually dismissed it (the problem was already solved anyway). As it turned out, there are ways to search for such hidden resources. Let’s see what you can hide and how to find it.
8 reasons to have microservices
Splitting a codebase. Small, and Focused on Doing One Thing Well.
At 1st Chapter of Building Microservices by Sam Newman, the author described the motivation.
Codebases grow as we write code to add new features, Over time, it can be difficult to know where a change needs to be made because of the codebase is too large. Despite a drive for clear, modular monolithic codebases, all too often these arbitrary in-progress boundaries break down. Code related to similar functions starts to become spread all over making fixing bugs or implementations more difficult.
With a monolithic system, we fight against these forces by tying to ensure our code is more cohesive, often by creating abstractions or modules. Cohesion – the drive to have related code grouped together – is an important concept when we think about microservices. This is reinforced by Robert C. Martin’s definition of the Single Responsibility Principle, which states “Gather together those things that change for the same reason, and separate those things that change for different reasons.”
What’s New in Java 14
March 17th was the release of JDK 14. The release is not LTS, but it contains several interesting new features. Let’s go over them.
Scripting and sandboxing in JVM
It’s a very common situation when an application needs some runtime customization, but it’s impossible via settings and you are too lazy to change source code, or you just cannot update your application too often. In that case you may use different script engines in order to change application behavior in runtime. Moreover, the developer doesn’t have to do changes themself. It may be the duty of administrators, analysts, etc
So, I want to describe the way of one java application, from the simplest script engine up to engines with secured sandboxes.
Integration with 3rd party APIs
There are many articles and books about good API design. But more often we connect to external systems via API, not developing.
I divide programming interfaces into two big sets – public and not so public. The first category – APIs of big companies like Facebook, Twitter, Paypal, etc. Generally, this kind of API is stable, developer-friendly and well-designed. The second category is APIs of small or middle-sized companies, state services and internal applications in big companies. This article will focus on the second set.