Machine Learning MOOC

It took a while but finally I’m done. It looks like everyone around me has already passed or abandoned “Machine Learning” MOOC from Stanford University on Coursera. So it was my turn to try this thing out.

Every week I had 2-3 early morning sessions of 2-3 hours each  in order to dive deeper into ML. Theory and quizes took around 2-3 hours each week, another 2-3 hours were spent on practical implementation. My fellow guys reported that parts of the theory were already taught for them in the university  However it was not the case for me. I clearly knew basic parts of working with vectors however things like linear regression were clearly out of scope in my curriculum. Practical tasks were not very difficult however you can always make some stupid mistake and chase it for hours. There were multiple runs of this course already. This means that all of the possible questions, issues and problems were discussed numerous times. Your just need to look for them.

I would say that the course is pretty balanced during weeks 2-9 and requires a bunch of work to be done and efforts to be applied. The last two weeks are pretty easy.

The course itself is amazing. It has a right combination of getting deep enough to get a sense of things, being not very detailed not to sink in maths  and being a good overview of the possible directions in the ML field. There is a lot to learn to become a professional in this field other than this course. However this MOOC definitely serves as an amazing entry point into this area. I really liked the way in which various parts were connected with each other. There was no any part of knowledge given for the sake of it. Every theoretical thing had a really important practical impact. And that’s what I liked the most in the course. It’s very practical and logical. It’s a real fun to see various pieces and ideas glued together to create a real-world output.

Actually it was pretty difficult not to abandon this course for me since it was really intensive. However I’m really happy to have it finished. We already did some application of the knowledge from this course during internal Fitbit hackathon and I guess it’s not the last time it was useful for me.

My huge appreciation to everyone who was involved in creating this course!

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

“Working in Teams: A Practical Guide” MOOC

Just finished Working in Teams: A Practical Guide MOOC on edX,

The goal for this course was to get a deeper insights on what can be better in my current team which I joined several months ago. Another intention was to reflect on my previous team and to see what possibilities I had missed.

The course is not really difficult: 7 sections should be passed in one month. Sections are not very big and it won’t take more than an hour per section even with doing all assignments and reviewing your peers. Due to this fact the course does not seem very deep. I would expect more assignments to be done. From the other side external test resources is a great source of understanding on where your team is now.

Key moments I’ve brought from this course:

  1. There is a more or less well-defined theory on team life-cycle and stages effective team passes through
  2. My current team is somewhere in between norming and performing stages according to the Tuckmans’ stages of group development.
  3. Belbin role model for team members seems fun but frankly speaking seems rather abstract. I didn’t find much value of using it in retrospective for some reason.
  4. High level of self-assertiveness is a must-have for a highly effective team along with a high level of communication. I was already coming to this conclusion myself and it was pleasant to see confirmation for it.
  5. There is a set of defined conflict resolution strategies for a team.
  6. Team leadership is a thing which should be done carefully and mindfully. A pretty good theory behind this one is available.

All of these points brought me to an idea that I could do much better in my previous team. I could definitely affect conflict resolution, assertiveness, motivation, communication and leadership aspects of it. This would probably make my previous team a more pleasant place to work.

However it’s all about experience and learning. I’m impressed by the level of communication and assertiveness in my new team. Hopefully techniques discussed in this MOOC will help me in making new team even more effective. This course is definitely well-worth studying so that you can make 8-9 hours you spend each weekday with your team a good and effective investment.

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

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.

OCP-JavaSE8-Programmer-clr

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 jprof.by 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.

Slides:

Kafka_in_production

Recording:

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-м годзе. Зразумела, што гэта толькі невялічкі кавалак, але было вельмі цікава. Нават я зразумеў што і як там адбываецца.

To-Do:

  1. Зразумець адрозненне wait-free ад lock-free
  2. Паглядзець якім чынам інмплеменціраваны AtomicInteger.increment()
  3. Прачытаць https://people.csail.mit.edu/edya/publications/OptimisticFIFOQueue-DISC2004.pdf
  4. Прачытаць https://people.csail.mit.edu/shanir/publications/Baskets%20Queue.pdf
  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. Шкада што іх няма офісу ў Мінску.

To-Do:

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

Having fun with Javassist – Anton Arhipov

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

To-Do:

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

GPars: Unsung Hero of Concurrency in Practice – Yaroslav Yermilov

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

To-Do:

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

Stream processing with Kafka streams – Dmitro Karpov

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

Micro optimizations in Java – Dmitriy Dumanskiy

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

ToDo:

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

How much do you cost? – Yegor Bugayenko

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

ToDo:

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

BoF

У рэшце рэшт! Гэта адбылося! Я ўпершыню пабываў на 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. Таксама былі спасылкі на некаторыя рэчы, пра якія я ня чуў раней. Неблагі пачатак для суботняй раніцы.

ToDo:

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

Resilient Design 101 – Avishai Ish-Shalom

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

ToDo:

  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 упор рабіўся на дэвелапераў, якія шукаюць праблемы ў кодзе. Гэтым разам рыторыка крыху змянілася і Нікіта распавядаў больш пра бізнэс, які не хоча губляць кліентаў з-за павольных транзакцый.

ToDo:

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

Lessons learned from Kafka in production – Tim Berglund

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

ToDo:

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

Highload reactive server with Netty – Dmitriy Dumanskiy

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

ToDo:

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

Object-oriented flavor for JUnit tests – Yegor Bugayenko

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

ToDo:

  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