Oracle Certified Professional: Java SE 8 Programmer

I’m continuing my certification efforts to confirm that I’m a programmer at least to myself.

It took a while to get prepared to the exam but finally I’ve got it passed with 88% of correct answers and got this nice badge.


I can hardly find exam questions difficult or very deep. Still it helped me to get into NIO.2 and ForkJoinPool which I didn’t use a lot during daily job. I can get some sleep now and start preparing my next presentation, probably on ZooKeeper, for the community.

Posted in Development, Education, Personal, Uncategorized | Leave a comment

Elegant Objects. Volume 1

It’s been a while since I’ve first heard of Yegor Bugayenko.

His blog, his conference talks(here, here and here), his podcast participation(here and here) already presented some of the pretty unusual OOP-related ideas. These looked like a bunch of colorful patches to me while they didn’t produce full picture.

So I was looking forward to have a look at the “Elegant Objects. Volume 1” book to see if it can make me a better programmer like it was declared for multiple times all over this book. Many thanks to Kiryl Karatsetski for giving me a chance to read this book.

I’m going split ideas from this book into three sections based on my personal attitude:

  1. Reasonable ideas
  2. Questionable ideas
  3. Harmful ideas

Here’s what I’ve got from this book.

Reasonable ideas

  1. Class naming:
    1. Name class for what it is, not what it does.
    2. “-er” suffix is a sign of something going wrong.
  2. There should be only one primary constructor and probably a bunch of secondary ones which call primary one as a result
  3. No code in constructor.
  4. Choose method names appropriately. It should be either a verb for manipulators or a noun for the builders. Boolean method naming also makes sense.
  5. Fake objects instead of mock objects in tests.
  6. Compact interfaces with the smart helpers inside.
  7. Do not use static methods
  8. Util classes are evil
  9. Method argument can’t be null
  10. Method result can’t be null
  11. Do not use public constants.
  12. Never use getters and setters. At least in your code.
  13. Don’t use type introspection.
  14. Use checked exceptions only

Questionable ideas

  1. Number of constructors can be around 5 to 10.
    Personally I prefer having less constructors and let client adjust things to my input rather than being able to accept whatever a client might pass
  2. Limit number of public methods to 5
    It seems like this concept is an evil when working with the database and you want results based on different queries.
  3. Limit a number of properties to encapsulate to 4.
    My personal number when I start thinking of decomposing the object is around 7.
  4. Always use interfaces.
    This facilitates having too much of a junk code you would never touch. You definitely don’t want to abstract everything you work with.
  5. Use only immutable objects
    It’s an idealistic unusable concept that has nothing in common with the real world programming. Still using immutable objects in the majority of cases is a good thing
  6. Do not use singletons
    It’s really nice that IoC frameworks like Spring can help us to hide complexity of instantiating and using singletons. Still I believe our code will become way more complex to read if we get rid of singletons
  7. Fail fast rather than fail safe
    There are too much conditions here. It might be totally fine if your deployment time is around several minutes and you’re ready to fix production issues any time, day or night. Otherwise you’ll definitely want to appear somewhere in between, probably closer to the “fail safe” side of the fence
  8. Catch exception on the highest level only
    This one is closely related to your position on the “Fail Fast -> Fail Safe” interval.
  9. Use AOP
    Well, it’s a powerful instrument but it’s a real pain for the praised maintainability. It’s a sort magic which appears in runtime from nowhere. Declaration of the pointcuts is really far from the classes which are affected by the aspect and thus not really flexible to work with. Plain Java annotations seem to be a more maintainable choice.
  10. Object should be either final or abstract
    I feel like limiting level of inheritance to just one is a rather good thing. However it’s still difficult to say how it plays with the real code without trying out.

Bad ideas

  1. Optional from JDK8 is a bad thing.
    Well it’s pretty limited in JDK8 and it looks pretty ugly in the code sometimes. Adding Optional::stream in JDK9 is clearly a step in the right direction/
  2. Use multiple level of object nesting to adjust behavior of the nested objects.
    The code becomes complex anf pretty much undebuggable. Those who tried to debug hierarchy of 30+ http filters would probably agree with me.
  3. Don’t use new out of secondary constructors
    Even book example has shown that it does nit make code simpler. Totally looks like an artificial unmaintainable concept.
  4. In the ideal world you would use If class instead of if statement
    I still believe that too much levels of object nesting is evil and makes code unreadable and undebuggable.

The book is definitely worth reading and thinking over the proposed concepts. However it’s really questionable that all of the book recommendations lead to the maintainable code. At least as I see it.

Posted in Development, Education, Uncategorized | Tagged | Leave a comment

Presenting “Kafka in Production”

Really glad to tell that my second public presentation really happened at JProf meetup.




This time way less time went into text repetition but way more time went into Kafka-related researches. 🙂
Even though I still have something to tell about Zookeeper – deferring this talk until becoming an OCPJP 8 certified programmer.

Posted in Conference, Education, Uncategorized | Tagged , , | Leave a comment

JEEConf 2017

Ізноў травень і зноўку захацелася ў Кіеў на канферэнцыю JEEConf. Лятаю я ў Кіеў за свае грошы. Было б бязглуздным вытрачаць свае грошы на тое, што не прыносіць задавальнення. Праўда?

Квіткі на самалет і на канферэнцыю былі набытыя яшчэ ў сакавіку. Хіба толькі калега, з якім я меўся паехаць, не змог выбрацца. Давялося ляцець аднаму.

Сонечная раніца, пахмурныя памежнікі, навюткі самалет Belavia, гадзіна чытання “The Art of Scalability”, не менш пахмурныя ўкраінскія памежнікі, усе такі ж надзіва ванючы аўтобус Skybus, сорак хвілін на метро, дваццаць хвілін пешкі ад Майдана, атрыманне бэджыка і са спазненнем на адзін даклад я станаўлюся паўнавартасным удзельнікам канферэнцыі.

І пачаліся даклады

Дзень 1

How threads help each other – Alexey Fyodorov

Аляксей усе пужаў-пужаў тым што даклад будзе складаным, але ніхто не сышоў. І правільна зрабілі, бо даклад атрымаўся цікавым. Напачатку Аляксей заклаў аснову распавеўшы як зрабіць lock-free push у стэк у шматпаточным асяроддзі. Потым Аляксей перайшоў да разынкі даклада. Ен расказаў пра lock-free далучэнне элемента у хвост чаргі на базе алгарытма распрацаванага ў IBM у 1996-м годзе. Зразумела, што гэта толькі невялічкі кавалак, але было вельмі цікава. Нават я зразумеў што і як там адбываецца.


  1. Зразумець адрозненне wait-free ад lock-free
  2. Паглядзець якім чынам інмплеменціраваны AtomicInteger.increment()
  3. Прачытаць
  4. Прачытаць
  5. Зразумець, дзе на ўзроўні жалеза выкарыстоўваюцца чэргі паведамленняў.
  6. Пашукаць блог Shavit і падпісацца
  7. Прачытаць “Сучасныя Аперацыйныя Сістэмы” Таненбаума
  8. Падпісацца на блог Nitsan Wakart

From Java to Assembly: Down the Rabbit Hole – Charles Oliver Nutter

Прыгажун-мужчына ў шэрым капелюшы з Red Hat паказваў шмат байткода, яшчэ больш асэмблернага кода згенераванага JIT, а таксама распавядаў як паспрабаваць дайсці да тых кавалачкаў з якіх вынікае як працуе ваш код. Адразу ж захацелася закасаць рукавы і прайсці тым жа шляхам, што і Чарльз. Нейкая ў мяне незразумелая слабасць да Red Hat і таго што яны робяць яшчэ з часоў Fedora Core. Шкада што іх няма офісу ў Мінску.


  1. Уключыць PrintInline і PrintAssembly і прайсці па кроках з прэзентацыі

Having fun with Javassist – Anton Arhipov

Дрэнны той евангеліст што не ўхваляе і не распавядае пра свой прадукт. Не без таго, але Антон даволі хутка пачаў свой аповяд пра JavaAssist. Не скажу што даведаўся шмат, бо гэта быў курс 101, але інтэрактыў з аўдыторыяў быў цікавы. А яшчэ я чарговы раз упэўніўся што разумны чалавек заўжды можа сказаць “Ня ведаю”, і гэта не праблема, бо ўсе нюансы ведаць немагчыма.


  1. Паглядзець XRebel
  2. Паспрабаваць падняць JRebel на наступным унутраным DevAwesomeness Day і зрабіць на базе вынікаў багрэпорт, бо відавочна не паднімецца. Мінулым разам, па меншай меры, не падняўся.
  3. Паглядзець магчымасці

GPars: Unsung Hero of Concurrency in Practice – Yaroslav Yermilov

На пачатку даклада Яраслаў шчыра здзіўляўся, чаму ж GPars ніхто не выкарыстоўвае ў продзе. Сапраўды, фіч там вельмі і вельмі шмат. Тут і агенты, і актары, і аўтаматычная пабудова графу выканання таскаў, і шмат чаго яшчэ. Вось толькі не праходзячае пачуцце чараўніцтва цягам усяго дакладу не пакідала. А вось у прадакшне не хацелася б магіі. Хацелася б прадвызначанасці і дакладнага разумення, як і што працуе. Ў любым выпадку, варта паглядзець гэты даклад, каб пабачыць і зразумець канцэпцыі, якія рэалізуе бібліятэка GPars.


  1. Чытаць user guide GPars
  2. Зразумець розніцу паміж замыканнем у Groovy і лямбдай у Java

Stream processing with Kafka streams – Dmitro Karpov

Перад дакладам я запісаў сабе спіс пытанняў, якія хацеў бы задаць. Там было і пра параўнанне з іншымі сістэмамі, і пра дэплоймент, і пра high availability, і пра захоўванне стану падчас працэсінгу. А Дмітро узяў і з імпэтам распавеў усе тое, што мяне хвалявала. Нават незразумела што ў ToDo пісаць. Чоценькі доклад.

Micro optimizations in Java – Dmitriy Dumanskiy

Самы неадназначны даклад першага дня канферэнцыі асабіста для мяне. Здаецца ўсе добра: кішкі, бенчмаркі, цікава, з тлумачэннямі. Але асноўныя пытанні кшталту “Нашто так сільнічаць Java замест таго каб узяць больш падыходзячы інструмент?” і “Як гэта падтрымліваць?” не атрымалі выразных адказаў, на мой погляд. Выглядала хутчэй як паззлеры с налетам перформанса, чым код, які варта пісаць у рэальных сістэмах.


  1. Зразумець што такое скалярызацыя
  2. Паглядзець што такое Integer.biCount() і для чаго выкарыстоўваецца ў свеце video працэсінга
  3. Паглядзець код сервера Blynk

How much do you cost? – Yegor Bugayenko

Чым больш я слухаю даклады Ягора, твм больш мне здаецца што ў яго словах есць праўда. Пэўна, мне ня варта часта глядзець на крышнаітаў. 🙂 Зразумела што рэальнасць не такая абсалютная і радыкальная. Але зерне ісціны там безумоўна есць. Не менш годным быў апошні выпуск падкаста DevZen і яго пасляшоў з удзелам Ягора. Гэткае выступленне матывуе падумаць, куды ж ты ідзеш і як прайшлі твае папярэднія гады. І гэта галоўнае, чаго я чакаю ад матывацыйных дакладаў. Падумаць і прааналізаваць свае жыцце ніколі не шкодзіць.


  1. Вытрачаць дзве гадзіны на тыдзень на StackOverflow
  2. Вытрачаць дзве гадзіны на тыдзень на HackerRank
  3. Абраць Open-Source праект бліжэй да сэрца і паспрабаваць пакантрыб’юціць


У рэшце рэшт! Гэта адбылося! Я ўпершыню пабываў на BoF на лакальных канференцыях. Нефармальная асяроддзе, фан і магчымасць даведацца што-небудзь новенькае. Яшчэ і крафтавае гуцульскае піва. Прыгажосць! Спачатку я пайшоў на сессію пра перформанс разнастайных кампанентаў enterprise сістэм, кшталту логгераў, ORM ды іншага. Але ж тэмы звязаныя з перформансам заўжды былі мутнымі. Ды і самая ідэя параўноўваць абстрактныя use case пад Windows(!) падалася мне не самай здаровай. У выніку гэта быў адзіны даклад за дзень з якога захацелася збегчы. Што я і зрабіў з дадатковай бутэлечкай смачнага піва ў руках. І збег я на Kotlin паззлераў. Я ніколі не карыстаўся Kotlin, але пакрысе прыглядаюся да яго. Нягледзячы на тое, что парог уваходу для Java-распрацоўшчыка зусім не высокі, там такооооога кода можна напісаць, что Java Puzzlers проста адпачываюць. Няхай пастаіць на палічцы і настаіцца да версіі 2.0. Сам фармат проста выдатна. Спадзяюся што арганізатары працягнуць BoF і ў наступным годзе. Хіба што я рэкамендаваў бы:
1. Адбіраць даклады, якія добра пасуюць менавіта фармату BoF
2. Рэкамендаваць дакладчыкам спажываць тое ж, што спажываюць наведнікі. Інакш пачуваешся няўтульна.
Kotlin Puzzlers вельмі добра адпавядаў гэтым крытэрыям і гэта тое, якім павінен быць BoF.

Дзень 2

Цікава? што на другі дзень арганізатары цалкам змянілі трэкі. І гэта было проста необходна. Думаю што пасля Whiskey Party шмат каму не зайшлі б гутаркі пра кішочкі JVM. Але пра ўсе па чарзе. Я вырашыў прапусціць Java Puzzlers. Фан, але карысці няшмат. За такі код трэба адбіраць ліцэнзію на праграмаванне.

Four real-world streaming application architectures – Tim Berglund

Тім паспеў распавесці пра 3 архітэктуры з чатырох. У прынцыпе, усе лагічна. ЦІкавым быў і пэўны гістарычны inside. Таксама былі спасылкі на некаторыя рэчы, пра якія я ня чуў раней. Неблагі пачатак для суботняй раніцы.


  1. Падпісацца на інжынерны блог Yelp
  2. Падпісацца на інжынерны блог LineCorp
  3. Паглядзець Metcalfe’s law
  4. Паглядзець што такое Kafka Schema Registry
  5. Паглядзець канцэпцыю Stream – Table duality

Resilient Design 101 – Avishai Ish-Shalom

Даволі добры архітэктурны даклад, які стараўся давесці што амаль ўсе на свеце есць чэргі з іх тыповымі праблемамі. Даклад цікавы тым, што Авішай распавядаў пра некаторыя рэчы, пра каторыя я дагэтуль ня чуў. Нейкая архітэктурная раніца атрымалася.


  1. Паспрабаваць зразумець чаму лок гэта па сваей сутнасці чарга
  2. Паглядзець што за HTTP код 503
  3. Паглядзець што за Little’s Law
  4. Паглядзець даклад Gil Tene “How NOT to measure latency
  5. Паглядзець рэальнасць выкарыстання канцэпцыі Timeout Budget

Introduction to Druid, fast distributed data store – Nikita Salnikov-Tarnovsky

Не мог прапусціць гэты даклад. NoSQL мяне цікавіць з часоў, як я пачаў заслухоўвацца DevZen. Больш за тое, мы час ад часу пазіраем у бок Time Series баз даных. А яшчэ калі пра гэта чытае Нікіта – трэба было ісці. Як звычайна, вельмі спецыфічны гумар і падыход, які мне даспадобы. Практычны погляд на тое, ці варта выкарстоўваць Druid і якія вельмі вузкія кейсы ен пакрывае. Цікавы момант збоку, які я заўважыў. Магчыма я памыляюся, але раней пры аповядзе пра Plumbr упор рабіўся на дэвелапераў, якія шукаюць праблемы ў кодзе. Гэтым разам рыторыка крыху змянілася і Нікіта распавядаў больш пра бізнэс, які не хоча губляць кліентаў з-за павольных транзакцый.


  1. Пачытаць user guide Druid
  2. Паглядзець што такое Tranquility
  3. Зразумець адрозненні Druid ад ElasticSearch

Lessons learned from Kafka in production – Tim Berglund

Даклад якога я вельмі чакаў. Да таго ж, план на ўступным слайдзе вельмі абнадзейваў. На жаль, Тім пакінуў толькі хвілін 10-15 на тэхнічныя падрабязнасці праблем і не палез углыб. Рэальна шкада. Проста расчараванне дня.


  1. Пашукаць, можа ўрэшце рэшт з’явілася Kafka сертыфікацыя без абавязковых курсаў Confluent

Highload reactive server with Netty – Dmitriy Dumanskiy

Ух які гэта быў даклад! Проста пярліна другога дня канферэнцыі. Даволі хутка, дакладна і без саплей пра Netty. На маю думку гэта проста ўзорны даклад ўзроўню 101. Шмат тэхнічных падрабязнасцей, відавочная абазнанасць Дзмітрыя ў тэме. Проста выдатна!


  1. Прачытаць Netty User Guide
  2. Паспрабаваць tutorials па Netty
  3. Паглядзець
  4. Паглядзець undertow
  5. Паглядзець ці ўключаны ў нас EPollSocketChannel на продзе
  6. Паглядзець які SSL binding ўключаны ў нас на продзе

Object-oriented flavor for JUnit tests – Yegor Bugayenko

Гэты даклад не мог быць звычайным. Усе мы ведаем рэвалюцыйныя погляды Ягора на праграмаванне ў Java. Цікава было, якім чынам гэта праявіцца ў юніт-тэстах. Тут, канешне, лепш глядзець даклад самастойна. Можа і зачэпіць. Мяне прымусіла задумацца, але ісці прапанаваным шляхам, на маю думку, ня варта.


  1. Паглядзець спіс TDD Antipatterns
  2. Спланаваць час на рэфактарынг нашых тэстаў
  3. Паглядзець на assertThat
  4. Паглядзець на Hamcrest
  5. Паглядзець TeeInputStream
  6. Падумаць, ці варта набыць і пачытаць Elegant Objects.

Персанальны топ 3 дакладаў

Тэхнічныя даклады:

  1. Highload reactive server with Netty – Dmitriy Dumanskiy
  2. From Java to Assembly: Down the Rabbit Hole Charles Oliver Nutter
  3. Stream processing with Kafka streams – Dmitro Karpov

Нетэхнічныя даклады:

  1. How much do you cost? – Yegor Bugayenko

Выдатна тое, што лакальныя даклады былі падрыхтаваныя ня горш, за даклады заезжых зорак. На маю думку, дык і лепш.

Агульныя маменты канферэнцыі:

  1. Нататнічкі ў гэтым годзе былі яшчэ больш прадуманымі. Больш тонкія, больш разумныя. Відавочны прагрэс.
  2. Ежа была смачнай. Неразнастайнай, але добрай. Дзякуй што былі  курыца і рыба. Не ўсе спажываюць чырвонае мяса.
  3. Кажуць што некаму не хапіла абеда ў першы дзень. Прызнаюся, я папрасіў тры кавалачкі курыцы замест двух і хлапец на раздачы незадаволена паглядзеў у мой бок, але ўсе ж такі паклаў яго. Выбачайце тыя, каму не хапіла, гэта часткова і мая віна.
  4. Лагістыка не змянілася ў параўнанні з папярэдняй канферэнцыяй і гэта добра.
  5. Якасць дакладаў значна падвысілася ў параўнанні з мінулым годам. Канешне, цалкам магчыма, я стаў больш переборлівым і стаў лепш абіраць тое, што мне цікава. Прычым даклады лакальнай камьюніці часам на галаву пераўзыходзілі даклады заезжых евангелістаў.
  6. BoF гэта крута!
  7. Добры Wi-Fi. Наогул не бачыў з ім праблем на асноўнай тэрыторыі. На верандзе – часам не лавіла.
  8. Гэтым разам больш настойліва прасілі апранаць бэджык. Давялося апрануць яго на заплечнік каб не адчуваць сябе каровай са званочкам на шыі.
  9. Магчымыя падарункі ад спонсараў, разыграныя ў латарэі былі нявартымі таго, каб даваць ім свае персанальныя даныя. Хіба толькі вандроўка ў Эстонію выглядала цікава. А тое, што на стэндзе спонсара нельга было нават ўзяць нататнік – гэта, выбачайце, проста сорам. Як і шкарпэткі разам з бананкай, што былі разыграныя ў латарэі! Добра што мне гэтым разам не хацелася нікому пакідаць свае кантакты і можна было проста крыху паржаць з гэткіх прэзентаў.

Увогуле, Кіеў увесну па-ранейшаму прыгожы і натхняльны. Цяжка з’ехаць з гэтага цудоўнага гораду без шматлікіх нататак і колькіх хайку. А неверагодная колькасць прыгожых дзяўчат разнявольвае думкі. Кожным разам Кіеў падабаецца мне ўсе больш і больш. А JEEConf – добрая нагода наведваць гэты цудоўны горад штовесну.

Posted in Conference, Development, Education, Uncategorized | Tagged , , , | Leave a comment

Force Return in Java

Lets say you’re in the debugging session and you would like to return some specific result from the method in your IDE. Usually I was using Variable window in order to achieve this. However there’s a way simpler approach available in IntelliJ and Eclipse named “Force Return”.

Screen Shot 2017-03-20 at 12.30.16

Screen Shot 2017-03-20 at 12.30.32

Posted in Development, Tips, Uncategorized | Tagged , , | Leave a comment

My First Public Presentation

It took me a while but here we are. Many thanks to the JProf community for providing an opportunity to present about MySQL to Cassandra migration at the meetup.

Slides can be found here.

It appears to be rather hard to prepare presentation. Raw estimates of the preparation time are the following:

  • 4 hours for the initial slides preparation
  • 6 hours for the initial text transcript
  • 10 hours for the internal review process and adjustments based on comments
  • 8 hours for the real meetup preparation
  • 2 hours for the meetup itself

So it took around 30 hours of work in order to have one hour presentation for the local meetup. Hopefully it’s all because I’m not an experienced speaker and next presentations will be at least 1.5 times quicker to prepare.

Key thing I’ve got from the presentation:

  • The more you learn about the topic of your presentation – the more gaps in your knowledge appear.
  • Questions is one of the most difficult parts of the presentation for me as a speaker. You don’t know answers to all of the possible questions and you have to start living with it. I just decided to stop at some point otherwise I would never present.
  • There are places available who welcome new speakers and provide reasonable feedback and friendly attitude towards newbies.
  • It would be way easier to start from the public 15-minute presentation rather than from the 45-minute one.
  • It won’t be really scary for you to present in front of 50 people – if you’re more or less prepared.
  • I’m not awful at doing presentations, just pretty bad.
  • It’s a sort of a pleasure to see people listening to you and understand that your presentation might unconsciously affect some of their choices in future.

I’m really glad I was given a chance to share our experience with the larger audience. It also helped to broaden my personal borders and reduce the fear of public presentations to a great extent.

Currently I’m considering topics for the presentations which are related to:

  1. Protobuf
  2. Kafka
  3. Migration from REST to Thrift
  4. Monitoring and alerting (StatsD + Graphite/Prometheus + Grafana + ELK)
  5. Developer life in the world of continuous delivery
  6. Streaming frameworks overview (more distant future)
  7. Heron streaming framework (more distant future)
Posted in Conference, Personal | Tagged , , | Leave a comment

Spring @Order in collections

It took me a while to understand why is the order not correct in the following code:

class A {
  @Autowired Collection<B> beans;
interface B {}
@Component @Order(1) class C implements B {}
@Component @Order(2) class D implements B {}

You’re welcome to guess why these are injected in the wrong order. No idea? What if I change it to List?

class A {
  @Autowired List<B> beans;

In this case ordered injection works properly. In general it makes some sense since Collection does not make any guarantees about the order. And I clearly understand framework designers here. Still this behavior is not clear from the first point of view.

Posted in Development, Uncategorized | Tagged , | Leave a comment