Technology

Essential for the operation of Java web applications. On our servers, we use Apache Tomcat; we can deal with deployment as well as clustered solutions. We have experience with applications operated on WebSphere and WebLogic. We’re not afraid of other servlet containers, either.

Many of us didn’t trust Bootstrap at the start, but we soon grew to like its options. Now we won’t lift a finger without it!

We design the fastest possible solutions with high accessibility, which is why for selected solutions we use CDN (Vshosting) combined with WAF (Incapsula).

Infrastructure automation using chefs and our own scripts. We can bake a new server in production form in a matter of minutes. So, thanks to Chef, we keep a configuration of hundreds of servers in a single/one lath.

We can implement various solutions, but for many reasons cloud-hosting is the most advantageous (on a Unix/Linux platform).

We want to test every change which we perform in the project as soon as possible. For this, we use tools such as Jenkins, Teamcity and GitLab.

We’ve been using cascade styles for two decades; for all of those twenty years, we’ve been troubled by older browsers which must be supported. Writing is CSS easier using LESS and since the arrival of Bootstrap 4 SASS.

One of the camps is leaning towards development in Eclipse, or more precisely STS. Freedom is important to us, so the choice of IDE is up to each of us, though the developer camp for IntelliJ Idea can’t comprehend this particular choice at all.

We like trying new things but we’re still enthusiastic about Elastic. It manages even the most complex queries faster than the traditional solution; and when we factor in its scalability, there’s no need for further explanations.

This is a re-established phenomenon. Although most of us studied semesters of Lisp in school, at our company we currently use it unsystematically only at the level of Java closures and streams, while some of us are flirting with Rx. But it’s definitely an area in which we’d like to move forward.

Years ago, we enthusiastically switched from an internal Microsoft Exchange and simple file server to G Suite. Now we can’t imagine company life without Gmail, shared data on Drive, Google docs, calendars and related applications from the Google package.

We used CVS for a long time, but now that’s a thing of the past. Most of us use GIT on a daily basis. We have an established branching model so that we can have several people working on a project and working on multiple tasks simultaneously.

Kind of like our own little GitHub. Aside from the clarification of authorisations and visualisation of changes, we avail ourselves of options for writing documentation (Markdown is super) and merge requests, and it’s our place for dealing with code review.

This has been used at our company for quite a while e for fast customisation in simpler projects and for integrating parts among multiple modules. However, recently we’ve come to prefer Java 8.

In 2016, we began using the open-source tool Mattermost; an alternative to Slack. For now, the positive aspects of this type of communication prevail.

Automation for developers. We use it primarily for deployment automation and to simplify toy local development, just like Yeoman for the establishment of a project.

To us, this is an inseparable duo for frontend development and tuning. Any web designer can easily develop the basic settings.

Essential to all of the solutions we operate. It serves as an input element which facilitates all types of configurations, typically as a HTTPS terminator and balancer.

Basic technology around which all web projects are constructed. We have gradually tread the path from HTML3, HTML4 (also called DHTML), through XHTML, up to today’s HTML5 standard.

IDE = Integrated Development Editor – a tool which brings the developer nearly everything. Every tool they need for their work.

The IDE most used by our developers. It enables us to be close to our code, and we love its user-friendliness and intelligence.

We operate our own informational intranet portal called Jáchym. It’s a well of all kinds of company information and communications. We’re preparing its younger brother, Hugo.

We program our solutions in the JAVA language. We avail ourselves of the options which Java 8 brings, while at the product level we still support JDK 7 so that our solutions can also run in the client’s environment, where upgrading their Java version is often more complicated. We’re diligently getting ready for Java 11.

Still an integral part of all projects. We’re very happy with the development which is taking place, even though the lifespan of some JS frameworks sometimes costs us a lot of effort. We’re also happy with the arrival of ES6, and we enjoy using its new features.

Still the fastest way to revive simple websites.

We have the complexities of JVM, including options for monitoring, security and accessibility, well under control. We’ve been operating Java on this server since v1.2.

For operational logging and finding information from logs, we use the internally operated open-source software package Filebeat, Elasticsearch, and for data visualisation we use Kibana. But whoever wants to (and has access to them) can browse logs on disk.

For building, we use Maven. We’re looking at Gradle, but ultimately Maven is simply the best way, with maximum support across all developmental tools.

This is the basis of our platform and is built on a composition of Spring application contexts within the scope of one classloader, which may change with the arrival of JigSaw. We’ve gotten relatively far with modularity – we use it to cover everything from the data layer to the UI. The key attributes are isolation, expandability and combinability.

Currently we have only a few installations which fulfil the task of an effective clustering solution for us. We like its simplicity, schemaless access and aggregation framework. It fully meets s our expectations, even though it has also given us a few wrinkles.

Operated solutions must be monitored. We use the internally operated open-source software Icinga and Zabbix. For the external monitoring of our web solutions, we chose Pingdom years ago.

Simplifies our work with the persistence of objects into the database. We like it much more than Hibernate, and in projects we often use our own solution (Adam). But we don’t look down on directly working with databases using the Spring JdbcTemplate either.

A fast database, and a wide selection of tools for both developers and operators ors. We can reasonably scale it and back it up; we know where its weaknesses lie and where, on the other hand, it performs better than Oracle.

Javascript on a server is no longer a specialisation; it falls within our solutions without any problems. And, we’re still entertained by the discussion about whether NPM is better than Maven.

These days a regular part of more complex solutions. However, we mostly combine it with a classic relational database, which serves as the primary depository for project data, and NoSQL then offers views for simple further presentation of this data.

This is the basis of our work, and although nowadays it’s being criticised for a number of deficiencies, we think that for now it’s the best we have for productive application development. Abstraction, delegation and composition, GOF patterns and many others are our daily bread.

For large clients, this is the first choice for a relational database. We’re able to use it, but we intentionally do not utilise options which are not transferable to other platforms.

A marginally faster implementation of MySQL, which we’ve been deploying for years instead of its archetype MySQL. At the API and functionality levels it’s identical to MySQL, but it works faster for us and offers more options like backup and cluster.

This Javascript library for UI rendering is not only widely discussed ; now it’s also widely used. At our company, we create applications which have really nice interactive interfaces on React. The surrounding ecosystem is quite extensive. For the data layer, we use the GraphQL platform Apollo. If server side rendering is needed, we use React combined with Next.js.

We guarantee that websites and web applications provided by us are optimised for various devices – from phones to tablets and desktops. For this, we use Bootstrap or, for example, dynamic pictures which ensure optimal data size for the device currently being used.

Automated penetration tests (using the Detectify online tool) are an integral part of our testing checklist. For more complex solutions, we can call in a manual capacity penetration test from the field (DCIT, Kümmel, Hacktrophy). When we find a fault, we distribute the repairs across all our solutions. By the way, nobody in the world has manufactured anything flawless... Remote access to servers – using OpenSSH to only a limited user group (only using their SSH keys) and only from listed IP addresses.

We make extensive use of the Spring framework, not only for dealing with dependency injection, but also for other parts such as Spring MVC, Spring Security, Spring Batch, etc. We also like the support for testing, web services, LDAP communication; in short, almost everything. :-)

We do this to make our work easier. The test isn’t always the first thing we write, but we don’t stop there. A large part of Java developers’ work progresses using only tests, without the need to launch an application server.

The development of our projects and their testing are inseparable. We manage this using unit tests (JUnit), integration tests (JUnit), and end-to-end tests (Webdriver). Our testers perform a final check (against the checklist), penetration testing (Detectify) and performance tests (Gatling). After the deployment of new versions, we always run automated smoke testing.

Allegedly the third most popular IDE at our company (so it is definitely in the top hundred), all the others have (again allegedly) long been trying in vain to catch up with the functions which this magical tool offers, which allows ViM users to look dismissively. Down at the rest of us.

The originally used Apache has gradually been replaced in our infrastructure by the more efficient NGINX. We also utilise it as a reverse proxy cache.

We use it for writing UI tests which verify functionality from a user’s perspective (end-to-end tests, acceptance tests). Tests of this type pay off primarily within the scope of product development, where every possible error can l affect multiple projects. We use automated testing combined with Browser Stack Automate.