Development

Java developers have access to a number of useful tools that help to write high-quality code such as the powerful IDE IntelliJ IDEA, free analyzers SpotBugs, PMD, and the like. The developers working on CUBA Platform have already been using all of these, and this review will show how the project can benefit even more from the use of the static code analyzer PVS-Studio.

SafeHandle / CriticalHandle / SafeBuffer / derived types

I feel I’m going to open the Pandora’s box for you. Let’s talk about special types: SafeHandle, CriticalHandle and their derived types.

This is the last thing about the pattern of a type that gives access to an unmanaged resource. But first, let’s list everything we usually get from unmanaged world:

The first and obvious thing is handles. This may be an meaningless word for a .NET developer, but it is a very important component of the operating system world. A handle is a 32- or 64-bit number by nature. It designates an opened session of interaction with an operating system. For example, when you open a file you get a handle from the WinApi function. Then you can work with it and do Seek, Read or Write operations. Or, you may open a socket for network access. Again an operating system will pass you a handle. In .NET handles are stored as IntPtr type;

This chapter was translated from Russian jointly by author and by professional translators. You can help us with translation from Russian or English into any other language, primarily into Chinese or German.

Also, if you want thank us, the best way you can do that is to give us a star on github or to fork repository github/sidristij/dotnetbook.

People are resorting to blockchain for all kinds of reasons these days. Ever since I started doing smart contract security audits in mid-2017, I’ve seen it all. A special category of cases is ‘blockchain use’ that seems logical and beneficial, but actually contains a problem that then spreads from one startup to another. I am going to give some examples of such problems and ineffective solutions so that you (developer/customer/investor) know what to do when somebody offers you to use blockchain this way.

Disclaimers

• The described use cases and problems occur at the initial stage. I am not saying these problems are impossible to solve. However, it is important to understand which solutions system creators offer for particular problems.
• Even though the term ‘blockchain use’ looks strange and I am not sure that blockchain can be used for anything other than money (Bitcoin), I am going to use it without quotes.

1. Supply chain management

Let’s say you ordered some goods, and a carrier guarantees to maintain certain transportation conditions, such as keeping your goods cold. A proposed solution is to install a sensor in a truck that will monitor fridge temperature and regularly transmit the data to the blockchain. This way, you can make sure that the promised conditions are met along the entire route.

Like any developer, you are constantly developing. You are learning new technologies by reading books, watching online lessons, attending some courses, and so on and so forth. You know that if you stop learning, you become uncompetitive. But have you ever thought about your performance? How do you improve that? If you don't know how to answer than welcome under the cut.

Let me share an interesting experience in promotion of a mobile game.

1. Introduction

I am going to describe all the benefits and of course show the final results. The example will be the mobile game Quick Brain which is available for Android и iOS. Quick Brain Android was released the first that's why its possibilities differ considerably from iOS version.

I have been always kept by the thoughts that everyone's talking about high returns in contrast with Android. I just couldn't resist such attractive prospects and started more active refinement of iOS version in order to feel less embarrassed about it.

After Google play iOS has become an absolutely new field for the games for me. During my comparative experiment I've found out that iOS version can bring comparable earnings to Android with daily audience 3 to 10 times less depending on the country.

There are a lot of posts about what a typical coding interview at Google looks like. But, while not as widely described and discussed, there is also quite often a system design interview. For an SRE position it’s NALSD: non-abstract large system design. The key difference between SWE and SRE interviews consists in these two letters: NA.

So, what is the difference? How to be prepared for this interview? Let’s be non-abstract, and use an example. To be more non-abstract, let’s take something from the material world, such that you won’t be asked the exact same thing at the real interview (at least, not at the Google interview) :)

So, let’s design a public library system. For the paper books, like you have seen everywhere around. The whole text below was written all at once within around one hour, to roughly show you the areas that you should be able to cover / touch during the interview. Please excuse some disorder, that’s how I think (therefore I am).

We all hear of iconic movies, games, books or musical compositions that get vehemently praised by the community of sophisticados, professionals and critics, yet never seem to attract tangible commercial success or the attention of the wider audience. Such situations leave me deeply frustrated.

When it comes to development, good tech also sometimes never gets into the limelight. Take F# for example. All I know about it is that it is a super-cool, yet totally unpopular language which makes it hard for developers – upon getting to know it – to get back to the languages they’re used to.

I tried to find out what is the story behind this. In fact, who are the people who use it and why are they doing this if the language is out of demand in business? To find answers, I joined the Russian-speaking F# community on Telegram – our round table for the discussion.

This project is aimed at creating an experimental device for emulating RFID labels of three widely available components. I simplified the explanation of the process so that it could be easily replicated. I also developed some helpful ideas along the way, including writing a special program for converting a serial number into the transmitted data, which will definitely prove useful.

I manage a team that designs and introduces in-house Kubernetes aaS at Mail.ru Cloud Solutions. And we often see a lack of understanding as to this technology, so I’d like to talk about common strategic mistakes at Kubernetes implementation in major projects.

Most of the problems arise because the technology is quite sophisticated. There are unobvious implementation and operation challenges, as well as poorly used advantages, all of those resulting in money loss. Another issue is the global lack of knowledge and experience with Kubernetes. Learning its use by the book can be tricky, and hiring qualified staff can be challenging. All the hype complicates Kubernetes-related decision making. Curiously enough, Kubernetes is often implemented rather formally – just for it to be there and make their lives better in some way.

Hopefully, this post will help you to make a decision you will feel proud of later (and won’t regret or feel like building a time machine to undo it).

I came to Mail.ru Group in 2013, and I required a queue for one task. First of all, I decided to check what the company had already got. They told me they had this Tarantool product, and I checked how it worked and decided that adding a queue broker to it could work perfectly well.

I contacted Kostja Osipov, the senior expert in Tarantool, and the next day he gave me a 250-string script that was capable of managing almost everything I needed. Since that moment, I have been in love with Tarantool. It turned out that a small amount of code written with a quite simple script language was capable of ensuring some totally new performance for this DBMS.

Today, I’m going to tell you how to instantiate your own queue in Tarantool 2.2.

2019 is coming to an end, and it's Christmas soon. It is also the time to grab all data and collect statistics and a rating of the most interesting Habr's articles for this period.



In this post the best articles and best Habr authors 2019 will be presented, I also will show some statistical graphs that I find interesting or unusual.

Let's get started.

A couple of reader alerts:

In order to (somewhat) simplify the description process and tighten the volume of the article we are going to write, it is essential to make a significant remark and state the primary constraint right away — everything we are going to tell you today on the practical side of the problematics is viable only in terms of TLS 1.3. Meaning that while your ECDSA certificate would still work in TLS 1.2 if you wish it worked, providing backwards compatibility, the description of the actual handshake process, cipher suits and client-server benchmarks covers TLS 1.3 only. Of course, this does not relate to the mathematical description of algorithms behind modern encryption systems.

This article was written by neither a mathematician nor an engineer — although those helped to find a way around scary math and reviewed this article. Many thanks to Qrator Labs employees.

(Elliptic Curve) Diffie-Hellman (Ephemeral)

The Diffie–Hellman legacy in the 21 century

Of course, this has started with neither Diffie nor Hellman. But to provide a correct timeline, we need to point out main dates and events.

There were several major personas in the development of modern cryptography. Most notably, Alan Turing and Claud Shannon both laid an incredible amount of work over the field of theory of computation and information theory as well as general cryptanalysis, and both Diffie and Hellman, are officially credited for coming up with the idea of public-key (or so-called asymmetric) cryptography (although it is known that in the UK there were made serious advances in cryptography that stayed under secrecy for a very long time), making those two gentlemen pioneers.

In what exactly?

CMake is a cross-platform system for automating project builds. This system is much older than the PVS-Studio static code analyzer, but no one has tried to apply the analyzer on its code and review the errors. As it turned out, there are a lot of them. The CMake audience is huge. New projects start on it and old ones are ported. I shudder to think of how many developers could have had any given error.

This is a short story about how PVS-Studio helped us find an error in the source code of the library used in PVS-Studio. And it was not a theoretical error but an actual one — the error appeared in practice when using the library in the analyzer.

PVS-Studio supports analyzing projects developed in C, C++, C#, and Java. You can use the analyzer under Windows, Linux, and macOS. This small article will tell you the basics of analyzing C and C++ code in Linux environment.

Installation

There are different ways to install PVS-Studio under Linux, depending on your distro type. The most convenient and preferred method is to use the repository, since it allows auto-updating the analyzer upon releasing new versions. Another option is to use the installation package, which you can get here.

Hi everyone!

I like Tox and respect the participants of this project and their work. In an effort to help Tox developers and users, I looked into the code and noticed potential problems that could lead to a false sense of security. Since I originally published this article in 2016 (in Russian), many improvements have been made to Tox, and I lead a team that re-wrote secure Tox software from scratch using the Rust programming language (check out Tox-rs). I DO recommend using tox in 2019. Let's take a look what actually made us rewrite Tox in Rust.

Original article of 2016

There is an unhealthy tendency to overestimate the security of E2E systems only on the basis that they are E2E. I will present objective facts supplemented with my own comments for you to draw your own conclusions.

Spoiler: The Tox developers agree with my points and my source code pull request was accepted.

As we wrote in the 2018-2019 Interconnected Networks Issues and Availability Report at the beginning of this year, TLS 1.3 arrival is inevitable. Some time ago we successfully deployed the 1.3 version of the Transport Layer Security protocol. After gathering and analyzing the data, we are now ready to highlight the most exciting parts of this transition.

As IETF TLS Working Group Chairs wrote in the article:
“In short, TLS 1.3 is poised to provide a foundation for a more secure and efficient Internet over the next 20 years and beyond.”

TLS 1.3 has arrived after 10 years of development. Qrator Labs, as well as the IT industry overall, watched the development process closely from the initial draft through each of the 28 versions while a balanced and manageable protocol was maturing that we are ready to support in 2019. The support is already evident among the market, and we want to keep pace in implementing this robust, proven security protocol.

Eric Rescorla, the lone author of TLS 1.3 and the Firefox CTO, told The Register that:
“It's a drop-in replacement for TLS 1.2, uses the same keys and certificates, and clients and servers can automatically negotiate TLS 1.3 when they both support it,” he said. “There's pretty good library support already, and Chrome and Firefox both have TLS 1.3 on by default.”

This is a second article out of a series «Citymobil — a manual for improving availability amid business growth for startups». You can read the first part here. Let’s continue to talk about the way we managed to improve the availability of Citymobil services. In the first article, we learned how to count the lost trips. Ok, we are counting them. What now? Now that we are equipped with an understandable tool to measure the lost trips, we can move to the most interesting part — how do we decrease losses? Without slowing down our current growth! Since it seemed to us that the lion’s share of technical problems causing the trips loss had something to do with the backend, we decided to turn our attention to the backend development process first. Jumping ahead of myself, I’m going to say that we were right — the backend became the main site of the battle for the lost trips.

Christmas has always been one of my favourite times of the year. For me, Christmas is a season that brings so much love, laughter, happiness, and other magical things into our lives.

I was born and raised in Spain, more specifically in Tenerife, a sunny subtropical island in the middle of the Atlantic Ocean just off the African coast. I have to say that Christmas in Tenerife is very different to my the last two Christmases I’ve spent in London since joining Badoo.

One amazing plus of living in London is that I have got to see snow for the first time in my life, real snowflakes falling from the sky. Just incredible!

Talking of snowflakes, I have an interesting story to tell you about something that happened to me one day in the office the last Christmas.  It was right before I was heading home to Tenerife to spend a few days with my family.

It just so happened that last December I’d been assigned a very interesting ticket with the following description

This is the second part of a post about the creation of a pipeline that can take a Sketch file and export all the icons included in the file, in different formats, for different platforms, with the possibility of AB testing each icon.

You can read the first part of the post here.



The Sketch files, with all the icons collected, styled and properly named, were ready. Now it was time to start writing the code.

Suffice to say, the process was very much a trial and error: after the important initial code core, developed by my team lead Nikhil Verma (who set the script foundations), I went through an incremental process that required at least three phases of refactoring and quite a few revisions. For this reason, I won’t go into too much detail on how the script was developed, but rather focus on how the script works today, in its final shape.