Our first internal code challenge was held during the end of the summer in e-Travel and ended on September 11th. The reason we came up with the idea of the challenge in the first place was to learn a bit more about some underlying technology that we often encounter in our line of work while having some fun at the process!
At pamediakopes.gr we have many applications built with Rails, each one generating a huge amount of logs. These logs are mostly used for monitoring/alerting and of course debugging. However, your application’s logs have the potential to help you get more insights on your applications and how they interact with other systems, without necessarily using sophisticated 3rd party applications. The challenging part is extracting valuable information and doing it fast! In an attempt to try to get more insights of what is happening during a request, we started experimenting with the idea of using specific information from our Rails logs in order to visualize service dependencies, template rendering and more.
Unit testing is an essential practice in software delivery. It builds confidence that our code works and provides a safety net that enables us to change it safely. However, while well written tests provide us with traction and momentum, poorly designed tests often act as impediments that slow us down. This welcomes the question: what “good” unit tests look like? In this article we examine some key properties that separate the wheat from the chaff, driven by a simple example.
Some time ago we implemented a method that identifies requests to our sites that seem to have been generated by anything else other than normal users - like scraping bots. This situation is unpleasant for us because these requests generate unwanted load to our infrastructure and also to our partners, without resulting in any income at all.
If you visit pamediakopes.gr, or any one of our sites, to start looking for a flight and you type in a few letters to select the place of origin, you will see how our autocomplete feature kicks in, suggesting places based on the letters you entered.
Simply put, a factory method is any method that encapsulates the logic of how instances of a particular class are created. Considering this loose definition, it might seem at first that to a large extent factory methods are little, if any, different from plain old class constructors. As we shall see however, they are a more powerful option that can help us write cleaner and more maintainable code.
In our CRM system, users are able to create cases and manage them through resolving their tasks. In order to keep track of all these tasks we provide a search interface.
At pamediakopes.gr we have a lot of systems and several external and internal HTTP APIs. Unsurprisingly, these systems often need to communicate between themselves to get work done and we routinely see tens of thousands of calls being made from system to system.