ALEXANDER CHERNYKH

Remove icons in Ubuntu 20.04 menu after uninstalling wine applications

noreply@blogger.com (Alexander Chernykh) — Sun, 11 Oct 2020 16:43:00 +0000

I've been searching for the solution every time and again I'm facing with this problem.

Imagine you have installed a program in wine and then decided to remove it.

wine uninstaller

then choose the program and that is it.

Unfortunately the icon of removed program still will be in the gnome menu.

To remove it go to

~/.local/share/applications

and remove folder with your program. After that the icon will gone away.

WebSocket API in Java

noreply@blogger.com (Alexander Chernykh) — Fri, 17 Jul 2020 12:29:00 +0000

Hi!

Ever wondered how many abstractions you have to learn in order to use the API?

I just started to read about websocket api in java and it seems you need a lot to understand in order be on the same wave.

Lets start with RFC 6455, then you need to read JSR-356.
You think this is enough? :-)

If you use Spring then it provides you with WebSocketConfigurer which mimicries the low level web socket api.

If you do not like to play with low level api, then you can use AbstractWebSocketMessageBrokerConfigurer which adds messaging model with queues and topics using STOMP over websocket api and fallback for the clients who do not have websocket at hand.

You can also add external message broker which will serve your messages.
But what about security?

You have to use AbstractSecurityWebSocketMessageBrokerConfigurer in order to configure security.

So, together with security this will be 5 apis\concepts you need to know just in order to play with web sockets.

Is not that much?

Documenting Web API

noreply@blogger.com (Alexander Chernykh) — Fri, 27 Dec 2019 10:37:00 +0000

A long time ago when SOAP was ubiquitous, WSDL was the only way to document your API.

There were two approaches - code first approach, and contract first approach. With code first approach you first develop your service and then with the help of library wsdl got generated. When you use contract first approach you develop WSDL description of your service and then code the service.

Now everyone doing REST. To document the service one could use RAML or swagger annotations. I have not used RAML, but I have used swagger. With swagger one can also use one of two approaches. Using swagger annotations were like a breeze. Now a good news. Swagger has been bought by SmartBear and renamed to OpenAPI Specification.
Now instead of swagger annotations we can use OpenAPI annotations.
With maven swagger plugin one can generate the specification during compilation time. Also there are plugins so that specification can be generated and accessed at runtime.
Apart from that new tools started to apper to work with OpenAPI specifications: editors, validators, report generators and so on. You can check https://openapi.tools for a list of tools.

There is a good introductory book to OpenAPI specification: The Design of Web APIs by Arnaud Lauret.
I specifically recommend reading chapters 4 and 12. Chapter 4 tells you how to create specification, chapter 12 tells about producing reports from the specification.

12-factor application methodology

noreply@blogger.com (Alexander Chernykh) — Tue, 02 Jul 2019 08:57:00 +0000

1. There should be a one-to-one association between a versioned codebase (for example,
an IT repository) and a deployed service. The same codebase is used for many
deployments.

2. Services should explicitly declare all dependencies, and should not rely on the presence
of system-level tools or libraries.

3. Configuration that varies between deployment environments should be stored in the
environment (specifically in environment variables).

4. All backing services are treated as attached resources, which are managed (attached and
detached) by the execution environment.

5. The delivery pipeline should have strictly separate stages: Build, release, and run.

6. Applications should be deployed as one or more stateless processes. Specifically,
transient processes must be stateless and share nothing. Persisted data should be stored
in an appropriate backing service.

7. Self-contained services should make themselves available to other services by listening
on a specified port.

8. Concurrency is achieved by scaling individual processes (horizontal scaling).

9. Processes must be disposable: Fast startup and graceful shutdown behaviors lead to a
more robust and resilient system.

10.All environments, from local development to production, should be as similar as possible.

11.Applications should produce logs as event streams (for example, writing to stdout and
stderr), and trust the execution environment to aggregate streams.

12.If admin tasks are needed, they should be kept in source control and packaged alongside
the application to ensure that it is run with the same environment as the application.

More at https://12factor.net/ru/.

The eight fallacies of distributed computing

noreply@blogger.com (Alexander Chernykh) — Tue, 02 Jul 2019 08:50:00 +0000

Distributed computing is a concept with roots that stretch back decades. The eight fallacies of
distributed computing were drafted in 1994, and deserve a mention:

1. The network is reliable.
2. Latency is zero.
3. Bandwidth is infinite.
4. The network is secure.
5. Topology doesn’t change.
6. There is one administrator.
7. Transport cost is zero.
8. The network is homogeneous.

See Fallacies of Distributed Computing
Explained, available at: http://www.rgoarchitects.com/Files/fallacies.pdf

Spring. @Component and Further Stereotype Annotations

noreply@blogger.com (Alexander Chernykh) — Wed, 22 May 2019 08:49:00 +0000

For reference:

1.10.1. @Component and Further Stereotype Annotations

The @Repository annotation is a marker for any class that fulfills the role or stereotype of a
repository (also known as Data Access Object or DAO). Among the uses of this marker is the
automatic translation of exceptions, as described in Exception Translation.

Spring provides further stereotype annotations: @Component, @Service, and @Controller. @Component is a generic stereotype for any Spring-managed component. @Repository, @Service, and @Controller are specializations of @Component for more specific use cases (in the persistence, service, and presentation layers, respectively).

Therefore, you can annotate your component classes with @Component, but, by annotating them with @Repository, @Service, or @Controller instead, your classes are more properly suited for processing by tools or associating with aspects. For example, these stereotype annotations make ideal targets for pointcuts.

@Repository, @Service, and @Controller can also carry additional semantics in future releases of the Spring Framework. Thus, if you are choosing between using @Component or @Service for your service layer, @Service is clearly the better choice.

Similarly, as stated earlier, @Repository is already supported as a marker for automatic exception translation in your persistence layer.

UML diagrams for java programmers. Robert C Martin. [Extracts]

noreply@blogger.com (Alexander Chernykh) — Wed, 03 Apr 2019 09:42:00 +0000

UML diagrams for java programmers. Robert C Martin.

When to draw diagrams, and when to stop.

Don’t make a rule that everything must be diagrammed. Such rules are worse than useless.
Enormous amounts of project time and energy can be wasted in pursuit of diagrams that
no one will ever read.

When to draw diagrams:
• Draw diagrams when several people need to understand the structure of a partic-
ular part of the design because they are all going to be working on it simulta-
neously. Stop when everyone agrees that they understand.
• Draw diagrams when two or more people disagree on how a particular element
should be designed, and you want team consensus. Put the discussion into a time-
box choose a means for deciding, like a vote, or an impartial judge. Stop at the
end of the timebox, or when the decision can be made. Then erase the diagram.
• Draw diagrams when you just want to play with a design idea, and the diagrams
can help you think it through. Stop when you’ve gotten to the point that you can
finish your thinking in code. Discard the diagrams.
• Draw diagrams when you need to explain the structure of some part of the code
to someone else, or to yourself. Stop when the explanation would be better done
by looking at code.
• Draw diagrams when it’s close to the end of the project and your customer has
requested them as part of a documentation stream for others.

When not to draw diagrams:
• Don’t draw diagrams because the process tells you to.
• Don’t draw diagrams because you feel guilty not drawing them or because you
think that’s what good designers do. Good designers write code and draw dia-
grams only when necessary.
• Don’t draw diagrams to create comprehensive documetation of the design phase
prior to coding. Such documents are almost never worth anything and consume
immense amounts of time.
• Don’t draw diagrams for other people to code. True software architects partici-
pate in the coding of their designs, so that they can lay in the bed they have made.

CASE Tools.

UML CASE tools can be beneficial, but they can also be expensive dust collectors. Be
very careful about making a decision to purchase and deploy a UML CASE tool.

• Don’t UML CASE tools make it easier to draw diagrams?
No, they make it significantly harder. There is a long learning curve to get profi-
cient; and even then the tools are more cumbersome than whiteboards. White-
boards are very easy to use. Developers are usually already familiar with them. If
not, there is virtually no learning curve.
• Don’t UML CASE tools make it easier for large teams to collaborate on dia-
grams?
In some cases. However, the vast majority of developer and development
projects do not need to be producing diagrams in such quantities and complexi-
ties that they require an automated collaborative system to coordinate their activ-
ities. In any case, the best time to purchase a system to coordinate the preparation
of UML diagrams is when a manual system has first been put in place, is starting
to show the strain, and there is no other choice but to automate.
• Don’t UML CASE tools make it easier to generate code?
The sum total effort involved in creating the diagrams, generating the code, and
then using the generated code is not likely to be less then the cost of just writing
the code in the first place. If there is a gain, it is not an order of magnitude, or
even a factor of two. Developers know how to edit text file and use IDEs. Gener-
ating code from diagrams may sound like a good idea; but I stronly urge you to
measure the productivity increase before you spend a lot of money.
• What about these CASE tools that are also IDEs and show the code and dia-
grams together?
These tools are definitely cool. However, I don’t think the constant presence of
UML is important. The fact that the diagram changes as I modify the code, or
that the code changes as I modify the diagram, does not really help me much.
Frankly, I’d rather buy an IDE that has put its effort on figuring out how to help
me manipulate my programs than my diagrams. Again, measure productivity
improvement before making a huge monetary committment.
In short, look before you leap, and look very hard. There may be a benefit to outfitting
your team with an expensive CASE tool; but verify that benefit with your own experi-
ments before buying something that could very well turn into shelfware.

But what about documentation?
Good documentation is essential to any project. Without it the team will get lost is a sea of
code. On the other hand, too much documentation of the wrong kind is worse; because
then you have all this distracting and misleading paper, and you still have the sea of code.

Documentation must be created, but it must be created prudently. Often the choice not
to document is just as important as the choice to document. A complex communication
protocol needs to be documented.

A complex relatoinal schema needs to be documented.
A complex reusable framework needs to be documented.

However, none of these things needs a hundred pages of UML. Software documenta-
tion should be short, and to the point. The value of a software document is inversely pro-
portional to its size.
For a project team of 12 people working on a project of a million lines of Java, I
would have a total of 25 to 200 pages of persistent documentation, with my preference
being for the smaller. These documents would include UML diagrams of the high level
structure of the important modules, ER diagrams of the relational schema, a page or two
about how to build the system, testing instructions, source code control instructions, etc.
I would put this documentation into a wiki, or some collaborative authoring tool so
that anyone on the team can have access to it on their screens and search it, and anyone
can change it as need be.
It takes a lot of work to make a document small, but that work is worth it. People will
read small documents. They won’t read 1,000 pages tomes.

Can code really be used to describe part of a system? In fact, this should be a goal of
the developers and designers. The team should strive to create code that is expressive and
readable. The more the code can describe itself, the fewer diagrams you will need, and the
better of the whole project will be.

In general, high level diagrams are more useful than low level ones.

One of the great fallacies of software development in the 1990s was the notion that
developers should draw sequence diagrams for all methods before writing the code. This
always proves to be a very expensive waste of time. Don’t do it.

Use Cases

The real trick to doing use cases is to keep them simple. Don’t worry about use case
forms, just write them on blank paper, or on a blank page in a simple word processor, or on
blank index cards. Don’t worry about filling in all the details. Details aren’t important
until much latter. Don’t worry about capturing all the use cases, that’s an impossible task
anyway.
The one thing to remember about use cases is: tomorrow they are going to change. No
matter how dilligently you capture them, no matter how fastidiously you record the
details, no matter how thoroughly you think them through, no matter how much effort you
apply to exploring and analyzing the requirements, tomorrow they are going to change.
If something is going to change tomorrow, you don’t really need to capture its details
today. Indeed, you want to postpone the capture of the details until the very last possible
moment.
Think of use cases as: Just In Time Requirements.

Writing Use Cases

Notice the title of this section. We write use cases, we don’t draw them. Use cases are not
diagrams. Use cases are textual descriptions of behavioral requirements; written from a
certain point of view.

What is a use case.
A use case is a description of the behavior of a system. That description is written from the
point of view of a user who has just told the system to do something particular. A use case
captures the visible sequence of events that a system goes through in response to a single
user stimulus.
A visible event is an event that the user can see. Use cases do not describe hidden
behavior at all. They don’t discuss the hidden mechanisms of the system. They only
describe those things that a user can see.

How can you estimate a use case if you don’t record it’s detail? You talk to the stake-
holders about the detail, without necessarily recording it. This will give you the informa-
tion you need to give a rough estimate. Why not record the detail if we’re going to talk to
the stakeholders about it? Because tomorrow the details are going to change.
Yes, but over many use cases those effects integrate out.
Recording the detail too early just isn’t cost effective.

If we aren’t going to record the details of the use case just yet, then what do we
record? How do we know that the use case even exists if we don’t write something down?
Write the name of the use case. Keep a list of them in a spreadsheet, or a word processor
document. Better yet, write the name of the use case on an index card and maintain a stack
of use case cards. Fill in the details as they get closer to implementation.

What else?
What about actors, secondary actors, preconditions, postconditions, etc. etc. What about
all that stuff?
Don’t worry about it. For the vast majority of the systems you will work on, you
won’t need to know about all those other things. Should the time come that you need to
know more about use cases, then you can read Alistair Cockburn’s definitive work on the
topic: Writing Effective Use Cases, Addison Wesley, 2001. For now, learn to walk before
you learn to run. Get used to writing simple use cases as above. As you master them
(defined as having successfully used them in a project), you can ever so carefully and par-
simonously adopt some of the more sophisticated techniques. But remember, don’t sit and
spin.

Of all the diagrams in UML, use case diagrams are the most confusing, and the least use-
ful. With the exception of the System Boundary Diagram, which I’ll describe in a minute,
I recommend that you avoid them entirely.

This diagram is almost, but not quite, useless. It contains very little information of use
to the Java programmier, but it makes a good cover page for a presentation to stakehold-
ers.

Design Quality

What does it mean to be well designed? A system that is well designed is easy to under-
stand, easy to change, and easy to reuse. It presents no particular development difficulties,
is simple, terse, and economical. It is a pleasure to work with. Conversely, a bad design
stinks like rotting meat.

Dependency Management
Many of these smells are a result of mismanaged dependencies. Mismanaged dependen-
cies conjure the view of code that is a tangled mass of couplings. Indeed, it is this view of
entanglement that was the origin of the term “spaghetti code”.
Object oriented languages provide tools that aid in managing dependencies. Interfaces
can be created that break or invert the direction of certain dependencies. Polymorphism
allows modules to invoke functions without depending upon the modules that contain
them. Indeed, an OOPL gives us lots of power to shape the dependencies the way we
want.
So, how do we want them shaped? That’s where the following principles come in. I
have written a great deal about these principles. The definitive (and most long-winded)
treatment is [Martin2002]. There are also quite a number of papers describing these princi-
ples on www.objectmentor.com . What follows is a very brief summary.

So, five simple principles:
1. SRP -- A class should have one and only one reason to change.
2. OCP -- It should be possible to change the environment of a class without chang-
ing the class.
3. LSP -- Avoid making methods of derivatives illegal or degenerate. Users of base
classes should not need to know about the derivatives.
4. DIP -- Depend on interfaces and abstract classes instead of volatile concrete
classes.
5. ISP -- Give each user of an object an interface that has just the methods that user
needs.
When should these principles be applied? At the first hint of pain. It is not wise to try
to make all systems conform to all principles all the time, every time. You’ll spend an eter-
nity trying to imagine all the different environments to apply to the OCP, or all the differ-
ent sources of change to apply to the SRP. You’ll cook up dozens or hundreds of little
interfaces for the ISP, and create lots of worthless abstractions for the DIP.
The best way to apply these principle is reactively as opposed to proactively. When
you first detect that there is a structural problem with the code, or when you first realize
that a module is being impacted by changes in another, then you should see whether one or
more of these principles can be brought to bear to address the problem.
Of course if you take a reactive approach to applying the principles, then you also
need to take a proactive approach to putting the kinds of pressure on the system that will
create pain early. If you are going to react to pain, then you need to diligently find the sore
spots.
One of the best ways to hunt for sore spots is to write lots and lots of unit tests. It
works even better if you write the tests first, before you write the code that passes them.
But that’s a topic for the next chapter.

Stories that are too long should be split. Stories that are too short should be merged. A
story should never be longer than three or four days worth of effort for the whole team.
They should never be shorter than about half a day’s effort. Stories that are too short tend
to be over-estimated. Stories that are too long tend to be under-estimated. So we merge
and join stories until they sit near the sweet spot of accurate estimation.

When designers create diagrams without methods they may be partitioning the soft-
ware on something other than behavior. Partitionings that are not based upon behavior are
almost always significant errors. It is the behavior of a system that is the first clue to how
the software should be partitioned.

One of the goals of OOD is the partitioning and distribution of behavior into many classes and
many functions. It turns out, however, that many object models that appear to be distributed
are really the abode of gods in disguise.

The lesson here is simply this: Associations are the pathways through which mes-
sages are sent between objects.

At no point did I need or want a UML diagram to help me with that design.
Nor do I think that the use of UML diagrams would have made the development more efficient or resulted in a superior design.

Ubuntu 18.04 and CiscoAnyconnect

noreply@blogger.com (Alexander Chernykh) — Sat, 02 Mar 2019 18:22:00 +0000

After installing Cisco Anyconnect I couldn't start it. That is really really sad.

In order to fix it I had to install:
sudo apt install libpangox-1.0-0

Now I can run ./vpnui and connect safely to my work PC.

JMM - Java memory model

noreply@blogger.com (Alexander Chernykh) — Sun, 29 Jul 2018 13:05:00 +0000

JMM
An archtecture's memory model tells programs what guarantees they can expect from the memory system, and specifies the special instructions required (called memory barriers) to get the additional memory coordination guarantees required when sharing data.

The JMM defines a partial ordering called happens-before on all actions within the program. To guarantee that the thread executing action B can see the results of action A, there must be a happens-before relationship between A and B. In the absence of a happens-before ordering between two operations, the JVM is free to reorder them as is pleases.

The rules for happen-before are:

Program order rule. Each action in a thread happens-before every action in that thread that comes later in the program order.

Monitor lock rule. An unlock on a monitor lock happens-before every subsequent lock on that same monitor lock.

Volatile variable rule. A write to a volatile field happens-before every subsequent read of that same field.

Thread start rule. A call to Thread.start on a thread happens-before every action in the started thread.

Thread termination rule. Any action in a thread happens-before any other thread detects that thread has terminated, either by successfully return from Thread.join or by Thread.isAlive returning false.

Interruption rule. A thread calling interrupt on another thread happens-before the interrupted thread detects the interrupt.

Finalizer rule. The end of a constructor for an object happens-before the start of the finalizer for that object.

Transitivity. If A happens-before B, and B happens-before C, then A happens-before C.

Failure at job interview

noreply@blogger.com (Alexander Chernykh) — Sun, 22 Jul 2018 15:35:00 +0000

What to do if you got rejected after the interview or you've just failed it?

Do not despair. Do not take rejection as your tragedy. Life is not only success. Often there are failures. This is not good or bad. This is just a norm of life.

After the interview try to understand which questions you couldn't answer?

Interview is a good opportunity to check your knowledge as well as to understand what the company is all about you are going to work on?

After you could identify your gaps in knowledge you can learn and fix it. Every subsequent interview increase your chances for success.

After every interview you increase the knowledge of market needs. In the end you'll land your job.

Concurrent collections. Java 8

noreply@blogger.com (Alexander Chernykh) — Sun, 08 Jul 2018 19:51:00 +0000

Concurrent collections.

What are the reasons to use new concurrent collections when we can use old plain collections using wrappers like Collections.synchronized(List/Set/Map)? The problem in this case will be that all accesses to the collection will use one lock. In its turn this will slow down performance.

We can ask what is the price in this case? For example take a look at HashTable and ConcurrentHashMap by the following link: https://www.ibm.com/developerworks/java/library/j-jtp07233/index.html.

Here are the results:
Threads    ConcurrentHashMap    Hashtable
1    1.00    1.03
2    2.59    32.40
4    5.58    78.23
8    13.21    163.48
16    27.58    341.21
32    57.27    778.41

Absolute numbers are not important but it is more valid to compare relative numbers.

What can we do about it? Maybe it will be better to write our own implementation of concurrent collection? It it possible but hard to achieve and more over there are already good implementations. Many useful concurrent collections are located at java.util.concurrent package.

Concurrent collections make synchronized collections largely obsolete.

That way instead of HashMap one can use ConcurrentHashMap.
In case when a number of search iterations outnumbers the number of adding or removing operations one can use CopyOnWriteArrayList instead of ArrayList.

As for the Queue implementations there are a lot of implementations:

    1. LinkedBlockingQueue — an optionally bounded FIFO blocking queue backed by linked nodes. An optionally-bounded blocking queue based on linked nodes. Linked queues typically have higher throughput than array-based queues but less predictable performance in most concurrent applications. The optional capacity bound constructor argument serves as a way to prevent excessive queue expansion. The capacity, if unspecified, is equal to Integer.MAX_VALUE. Linked nodes are dynamically created upon each insertion unless this would bring the queue above capacity.

    2. ArrayBlockingQueue — a bounded FIFO blocking queue backed by an array. A bounded blocking queue backed by an array.

    3. ConcurrentLinkedQueue - An unbounded thread-safe queue based on linked nodes. This queue orders elements FIFO (first-in-first-out). This implementation employs an efficient non-blocking algorithm based on one described in Simple, Fast, and Practical Non-Blocking and Blocking Concurrent Queue Algorithms by Maged M. Michael and Michael L. Scott.

    It is not obvious which implementation to use? It depends. One should choose the implementation based on tests.

    4. PriorityBlockingQueue — an unbounded blocking priority queue backed by a heap. An unbounded blocking queue that uses the same ordering rules as class PriorityQueue and supplies blocking retrieval operations.

    5. DelayQueue — a time-based scheduling queue backed by a heap. An unbounded blocking queue of Delayed elements, in which an element can only be taken when its delay has expired.

    6. SynchronousQueue — a simple rendezvous mechanism that uses the BlockingQueue interface. Synchronous queues are similar to rendezvous channels used in CSP and Ada. They are well suited for handoff designs, in which an object running in one thread must sync up with an object running in another thread in order to hand it some information, event, or task.

7. In JDK 7, TransferQueue is a specialized BlockingQueue in which code that adds an element to the queue has the option of waiting (blocking) for code in another thread to retrieve the element. TransferQueue has a single implementation:

    LinkedTransferQueue — an unbounded TransferQueue based on linked nodes. This implementation outperforms SynchronousQueue by factor of 3 to 14. See http://cs.oswego.edu/pipermail/concurrency-interest/2009-February/005886.html.

Deques and work stealing.
    Just as blocking queues lend themselves to the producer-consumer pattern, deques lend themselves to a related pattern called work stealing.

Java. How to start learning threads.

noreply@blogger.com (Alexander Chernykh) — Thu, 05 Jul 2018 16:05:00 +0000

There are a lot of different ways to start learning Java threads.
Here is my approach to learn threads:

Read the Java language tutorials on concurrency at https://docs.oracle.com/javase/tutorial/essential/concurrency/index.html.
Learn basic constructs like synchronized and volatile.
Learn about Dinning philosophers problem.
Read Effective Java Programming Language guide 3rd edition section 11 Concurrency:

Item 78. Synchronize access to shared mutable data
Item 79. Avoid excessive synchronization
Item 80. Prefer executors, tasks and streams to threads
Item 81. Prefer concurrency utilities to wait and notify
Item 82. Document thread safety
Item 83. Use lazy initialization judiciously
Item 84. Don't depend on the thread scheduler

Try to read Java Concurrency in Practice.

I'm not sure I have covered everything, but it is a good ground to start with.
Regards.

Java synchronized keyword

noreply@blogger.com (Alexander Chernykh) — Sun, 01 Jul 2018 15:16:00 +0000

Java multithreading has 2 key aspects - visibility and automicity.

For synchronization in Java one can use synchronized keyword.
Keyword synchronized is not equivalent to atomic, but synchronization can be used to achieve atomicity.
When subclassing a class overridden method should also define synchronized in its signature.
A synchronized method can call another synchronized method on its own instance.

Java volatile keyword

noreply@blogger.com (Alexander Chernykh) — Sat, 30 Jun 2018 14:46:00 +0000

According to Java Language Specification 8 section 8.3.1.4:
"As a rule, to ensure that shared variables are consistently and reliably updated, a thread should ensure that it has exclusive use of such variables by obtaining a lock that, conventionally, enforces mutual exclusion for those shared variables.

The Java programming language provides a second mechanism, volatile fields, that is more convenient than locking for some purposes.

A field may be declared volatile, in which case the Java Memory Model ensures that all threads see a consistent value for the variable" .

Please note, that volatile doesn't imply atomic. So that if your code is like this:
private volatile int var = 0;
var = var+1;
and you run increment in 2 threads then result won't be 2 in all situations.
In other words volatile fix visibility problems but not race conditions.

I recommend to go by following link https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.3.1.4 and take a look at example.

From Concurrent programming in Java 2nd:

Declaring a reference field as volatile does not ensure visibility of non- volatile fields that are accessed via this reference.
Similarly, declaring an array field as volatile does not ensure visibility of its elements.
Volatility cannot be manually propagated for arrays because array elements themselves cannot be declared as volatile.

Declaring fields as volatile can be useful when you do not need locking for any other reason, yet
values must be accurately accessible across multiple threads. This may occur when:

The field need not obey any invariants with respect to others.
Writes to the field do not depend on its current value.
No thread ever writes an illegal value with respect to intended semantics.
The actions of readers do not depend on values of other non-volatile fields.

Stages of the programmers interview

noreply@blogger.com (Alexander Chernykh) — Thu, 28 Jun 2018 21:36:00 +0000

Here is a short list of possible stages of the interview.

Phone screening. Usually is conducted by recruiter to assure that your phone is correct and you remember what is written in your resume. :-)
Time spent: 20-30 minutes.

Tet-a-tet meeting or Skype interview. This meeting is usually a technical interview where people try to check what you know and what you don't. Resembles like an oral exam. If you prepared well then you can come through it. But sometimes you are given a task which you need to solve or design a system.
Time spent: 1-1.5 hours.

Technical test over the Internet. As a rule you are given some time for a couple of easy technical tasks or a test with answer options. Many companies have their own platforms for such tests, but as a rule no one is supporting them, but the tests are chosen from a given limited set.

But there are exceptions. Some companies use third party sites which provide tests with different type of difficulty: from the middle one to hardcore.
Time spent: 1-1.5 hours.

Testing task. Usually you are given a code for refactoring or being asked to write a simple implementation of some task like a REST controller. It is not recommended to spend more than 3-4 hours on it. The less the better. Value your time. If necessary you can add something by saying when your task will be reviewed. If you are given a real peace of code and asked to do some "production" task then it is better to deny such offer as it may turned out that a company is doing its job for free.
Time spent: 1-3 hours.

Live coding. The most stressful part. People are watching you and how you code. Imagine how your productivity goes down with this approach? Usually no difficult tasks are given, but it is easy to fail. People try to check how you think, but in my opinion this way allows only to check your stress resistance.
Time spent: 0.5-1 hour.

Meeting with manager. At this stage manager is trying to understand how adequate you are and who you are from a business point of you? Are you a team player?
Time spent: 0.5-1 hour.

Mostly this is it. Usually there are no more then 3 stages including phone interview. This process is
very time consuming for you and a company. So it is better to keep short all the stages as possible.

If we'll talk about time then if we sum up all the timings it will be between 4 hours 20 minutes and 8 hours. Usually not all stages are being conducted. For example live coding is often omitted. This timings doesn't include your questions to the company. So expect to add between 0.5 and 1 hour for your questions and company's answers.

Java 8 programming interview questions

noreply@blogger.com (Alexander Chernykh) — Thu, 28 Jun 2018 19:26:00 +0000

Hi all.
I decided to share with you some stuff which could be useful for the beginners.

Every time you go to the Java interview you almost always get the familiar set of questions. Here is the list of questions that in my opinion are commonly asked at the interviews.

I won't give answers in this post for now. Feel free to explore them on your own.

Class Object in Java. Methods equals, hashCode, toString. Default implementation.
StringBuilder and StringBuffer. What is the difference? Compare strings by == and equals. String pool.
Collections. Basic interfaces and collections. ArrayList and LinkedList. HashMap default implementation. Difference between HashMap and LinkedHashMap and TreeMap.
Threads. Thread class. Interface Runnable. Monitor object. Methods wait, notify, notifyAll. Interface Executor. Synchronized keyword. Volatile keyword. Thread-safe collections. Dining philosophers.
Difference between interface and abstract class.
Lambda expressions. Default methods in interfaces.
Exceptions. Checked and unchecked. Difference.
Keyword final on class, method, instance member variable, method argument.
Try/catch/finally. Cases when finally block will not get executed.
Basic principles of garbage collector.
GoF templates. Examples. Do not mention Singleton. Visitor, Adapter, Builder, Template method, Strategy.
Basic SOLID principles.
What is TDD?

One of my favorite question is the following: you've got a class which contains one synchronized and one non synchronized method. What will happen if on one instance of this class will operate two threads, one will call synchronized method the other one will call non synchronized method? Is it possible to occur at once?

Answer: One thread can call synchronized method and another one can call non synchronized method. Synchronized keyword means that a thread needs to obtain object's monitor first. If there are no such word on a method then nothing stops the second thread to operate on an object.

Usually there are other questions about Spring, Databases, J2EE but let's leave it for now.

That is all for now. Good luck!

Java 8. Files.lines() can cause possible resource leak.

noreply@blogger.com (Alexander Chernykh) — Sat, 21 Apr 2018 11:25:00 +0000

Files.lines() method allows to receive stream of lines from file.
It seems to be very convenient apart from one thing - it can cause resource leak.
You must close this stream explicitly or use try with resource block.

It seems to be strange that terminal operations in this case doesn't close the resources underneath a stream.

Kotlin. Good point.

noreply@blogger.com (Alexander Chernykh) — Sat, 07 Apr 2018 19:12:00 +0000

Hi!
Long time no see.

What I'm currently observing is the rise of Kotlin language. Kotlin is the child of JetBrains company which brought to us IntelliJ.
Why Kotlin could in the future replace Java? What are the selling points of Kotlin?
Let's try to figure this out:

Kotlin works on JVM.
Kotlin can use all the java libraries.
Java can call code written in Kotlin.
Kotlin is open source.
Kotlin is developed and supported by JetBrains.
Google officially supports Kotlin as a second development language on Android platform.
IntelliJ has very good support tooling for Kotlin.
Spring Boot supports Kotlin.
Spring Framework 5 supports Kotlin.
Kotlin can be translated to java script.

With Kotlin you can migrate the project in Java in small steps.

Is not it enough to sell Kotlin to management and start using it in production?

Prolog ideas

noreply@blogger.com (Alexander Chernykh) — Mon, 25 Dec 2017 17:57:00 +0000

Here is my list of Prolog ideas:

JSON parser
HTTP requests parser
Declarative UI
Validation rules for UI
Business logic in C\C++\Java

The idea of declarative UI I borrowed from the Turbo Prolog 2 User guide and Turbo Prolog Toolbox. It could be useful to have some intermediate UI form representation in order to be able to translate it into different languages.

As for the last topic it turned out to be easy embed tuProlog in Java. And I had a prototype where I call java methods from Prolog.

The later topics need to be researched further.

Turbo Prolog 2.0. Changes from 1.x.

noreply@blogger.com (Alexander Chernykh) — Mon, 25 Dec 2017 15:40:00 +0000

Turbo Prolog 2.0 change list

- external database support with protected memory access

- BGI interface support

- improved text editor

- ability to save trace to file

- integers overflow check

- stack check

- error level

- ability to call prolog predicates from Turbo C

- conditional compilation support (ifdef, ifndef, elsedef, enddef)

- standart trap predicate

- build with Turbo C 1.5

W.F. Clocksin, C.S. Mellish. Programming in Prolog

noreply@blogger.com (Alexander Chernykh) — Thu, 21 Dec 2017 09:35:00 +0000

Hi everyone.

I have just read "Programming in Prolog" and wonder why this book is recommended for beginners?

The most useful tip in this book is located at the end of it in appendix C:

This book describes Prolog version which is not related to any particular existing version. The idea was to create the description of "general" Prolog which applies to all systems at once.

The best way to learn Prolog system you have -- is to read user documentation supplied with it.

Wow! Such a wonderful advise. Why I have to read all the book till the end in order to find out this?
Beginners will suffer a lot and will complain about Prolog. This shouldn't be like this.

Please treat the book as an approach to explain ideas behind Prolog, not a tutorial.

Adventure in Prolog

noreply@blogger.com (Alexander Chernykh) — Fri, 24 Nov 2017 09:13:00 +0000

Ever wanted to learn logic programming?
Wanna know how to program in Prolog?

Wanna know how to integrate Java with Prolog?

A lot of questions arise when we face with a "new" language such as Prolog.
After Java, Prolog looks like a fresh air. It has simple syntax, small number of concepts comparing to the OOP. For me the main advantage that it is a declarative language, not imperative.

If you deal a lot with business rules in your programs you know how ugly imperative implementations look like. This could be the opportunity for Prolog and constantly changing business world.

A lot of information exist about Prolog. What to start with?
IMHO Adventure in Prolog could be a good introduction to Prolog. All concepts are introduced and presented with examples and small tasks.

Examples could be run on almost any Edinburgh compatible Prolog. I use tuProlog. It runs on top of the JVM. Also it has a simple IDE, so you can just move straight to executing your code.

I also started a new repo on https://github.com/chernykhalexander/PrologExperiments for Prolog experiments.

Blog promotion

noreply@blogger.com (Alexander Chernykh) — Thu, 05 Oct 2017 20:44:00 +0000

Hi everyone!

It is been a while since I wrote here. But in order to give some excuse I would like to present you the blog of a programmer: http://www.yegor256.com/.

Why do I post it here? Well, I like that this man has his own opinion and he express it. A lot of computer topics are described - not only programming techniques, but management also. What is more - his opinion could be against with what everyone silently agree on. I like it. The more different angles of view we have at the topic the faster we can improve ourselves.

The same thing could be applied to the project. I do not like when everyone is silently agreed on something in a project. If all the team is agreed on it means that either no one doesn't care about the project or there is no atmosphere where each member can express their opinion safely.

Let's improve our projects.

My top Android applications

noreply@blogger.com (Alexander Chernykh) — Wed, 30 Aug 2017 09:53:00 +0000

I was disappointed that Microsoft doesn't produce windows phones any more and Nokia was sold. I have bought recently an Android phone Motorola Moto G4 plus and discovered Android and Play market.

Android seems to be very attractive and positive. I use version 7. I like fingerprint authentication very much. But... Why by default a lot of settings are turned on considering information sharing and statistics gathering? I need to go through the settings of Android and apps and turn off spy features.

Play contains a lot of apps but a lot of them are a crap. I have also a concern why actually some applications asks for a permissions not related with a purpose of application? That is why it is better not to install the application but instead use web site.

But anyway I decided to create my own top of applications I use.

Productivity and entertainment:

Skype
Whatsapp
Google Chrome
Google Gmail
Google Maps
Google YouTube
Google Photos
Google Calendar
Google Translate
RAR
micro Mathematics
TuneIn Radio
Aviasales
Gazeta.ru
Moto File Manager
Pocketbook
FM Radio

Technical apps:

Speedtest
CPU-Z

What are your favorite apps on Android?

Static versus dynamic functional languages

noreply@blogger.com (Alexander Chernykh) — Wed, 23 Aug 2017 14:20:00 +0000

Here is a nice post about choosing your future language:
http://blog.samibadawi.com/2016/03/static-vs-dynamic-functional-languages.html.