Screenshot from the game “Cities: Skylines”. Clickable This post is a small research I decided to carry out after reading an article about a city in Russia. In particular, I am going to consider the feasibility of building a city of hexagons. Since I don’t know any program or any other professional tool for simulating cities and moving vehicles in cities, I’ve decided to carry out a study in the “Cities: Skylines” game as it’s quite suitable for this purpose.
15 years ago, there was no Facebook. There was no C++ compiler with the diagnostic messages in Russian (my native language). Several C++ standards have been released since then, and technologies have made a huge leap forward in development. Today, having so many various frameworks, it doesn’t take too long to write a code analyzer or a programming language of your own. This post is about how I started my career and reached an expert level by means of self-development and writing a C++ compiler.
Demo: link Sources: link Working for the first time on the implementation and customization of Google Maps I couldn’t find any article to contain the whole scope of information and details, so I had to glean information on this issue, but mostly to come up with my own ideas. Afterwards I decided to write this article for those who have either no experience of working on styling Google Maps and their customization or lack time (or maybe lack the will) to learn API perfectly, thus making it easier for them to find information on the issue.
IT conferences and meetings on programming languages see a growing number of speakers talking about static code analysis. Although this field is quite specific, there is still a number of interesting discussions to be found here to help programmers understand the methods, ways of use, and specifics of static code analysis. In this article, we have collected a number of videos on static analysis whose easy style of presentation makes them useful and interesting to a wide audience of both skilled and novice programmers.
In May 2016, German game-development company Crytek made the, decision to upload the source code of their game engine, 'CryEngine V' to GitHub. The project is in active development, which leads to a large number of errors in the code. We have already checked the project with PVS-Studio for Windows, and now we can also analyze it using PVS-Studio for Linux. There was enough material for an article with the description of only crucial errors.
At the HighLoad++ conference in 2016, the development manager of “M-Tex” Vadim Madison talked about growth from the system, for which a hundred of microservices seemed a huge number, to a high-load project, in which a few thousands of microservices is a common thing. I will tell you how we launched microservices on quite a high-load project. It’s rather an aggregate experience but since I work for M-Tex, let me tell you a couple of words about who we are.
Disclaimer: this article is a translation. Original post was published in June, 2015. The first part is here. Let’s go on. For seven f*cking years, I’ve been waiting for a programming language that would meet my requirements. During this time, I’ve tested everything. Everything means all the general-purpose crap and all the not-quite-general-purpose crap. You can’t feel a language only by reading about it and writing “Hello, World!”. To understand the language, you should write at least something with it.
This article is based on Your Language Sucks in the form of half a joke. In the mentioned article, most of the “problems” are either synthetic and rarely used, or far-fetched due to expectations of the language correspondence to a theoretical paradigm the language should correspond to. On the other hand, the article misses a few things that really complicate my life as an engineer. I’m not claiming to have an absolute knowledge of Kotlin, so there can be some mistakes in the article.
You might think that it’s easy to write in PHP, and that “Hello, world” looks something like this: <?php echo 'Hello, world!'; Well, what else could one expect from a language with such a gentle learning curve? That’s exactly how it used to be. A long time ago. But now, in 2017, no one does it this way. Let’s see why, and try to build a more realistic hello-world application step by step.
In the first part of the article, I will enumerate lots of UNIX cheap and dirty hacks, and other various drawbacks. In the second part, we’ll talk about the UNIX philosophy. This article was written hastily, and I don’t want to further improve it. You’re lucky I wrote it. Therefore, I may provide some facts without source links. Dirty hacks in UNIX started to arise when UNIX was released, and it was long before Windows came to the scene, I guess there wasn’t even Microsoft DOS at the time (I guess and I don’t bother to check, so check it yourself).