In the heart of software development, in the city Brno, we launched a blog about IT.
One tricky task came recently out with feature we were implementing. Fetch Java logs in memory and save them to the database. This pretty clear goal turned out to be not as trivial task as we thought. At the same time, it turned out to be realizable in the short time after some research.
The number of models your organization must manage is increasing every year. Models are often registered in tools like Excel that are excellent for a particular type of task but are certainly not ideal as inventory tools to track current status, search for different criteria, or manage a variety of workflows associated with the model's life cycle.
Almost every software developing company runs a build server(s). As the team updates the codebase, the server is continuously building the project and when someone introduces compile/test breaking problem, build fails.
Yet another boring conference attended by a sleeping audience with the highlight being a piece of mediocre cheesecake served during a refreshment break? Model Risk Management Europe 2019, held in London, was without a doubt the very opposite!
When we started with the implementation of IFRS 9 standard, we had about a year to design and come with working and hopefully an extendable and robust solution. Since most of our developers are comfortable with Java and we built other projects using this language, the decision to built a core of application on Java Spring framework was easy.
In the previous blog post, I wrote about our problem with JVM CodeCache. This cache is used for saving compiled machine code and if your Java application generates new code on the fly, it will eventually fill.
As a Java developer, you don't need to know internal details of JVM most of the times. The virtual machine is not a trivial piece of technology and learning internal details can be scary. But there are times, when you find something interesting in the logs, which seems to be important. Like the message: CodeCache is full. The compiler has been disabled. Try increasing the code cache size using -XX:ReservedCodeCacheSize=
For our internal purposes and also for several of our customers we either introduced or used Atlassian JIRA. We see this tool as an amazing platform which can serve purposes of software development teams but also to entirely non-IT related projects. One of the small problems that we faced was rendering a screen of an issue with many subtasks. Simply to get an overview of all the subtasks which belong to a common parent means lots of clicking to the parent and then another subtask.
I use Google a lot in my job. Not only to search things I don't know, but also things I should know very well. For a long time, I didn't feel good about it. Until, I read this stream of confessions from skilled senior developers on the Twitter. As a developer interested in graphics, I should know that using references isn't bad. Graphics use references all the time and they don't feel bad about it. In fact, it is advised to use them. The final result is what matters.
My question targets not only desktop software but also mobile apps, web applications, and websites. Seems like software is getting worse and it won't be better. And I just have to start my rumble with the worst - mobile apps.
Sooner or later it is inevitable to secure your database. At least in my opinion... It was the first time I was securing a MongoDB instance and when I was looking for some information I came across this blog post. At first, if you want to set up username&password authentication for your MongoDB instance, you will find the article really helpful. Secondly, you can take much more from the post...specifically almost 600TB of data from all around the world (if you wish of course).
I just recently saw someone joking about Scrum on the Twitter. He wasn't very fond of Scrum because by his own words, "What kind of methodology is it, when it needs a single dedicated person to enforce it?" We are talking about Scrum Master role here. I'm having many problems with this statement.