Tuesday, 19 July 2016

New Season's Android Talks are here!

Since I finished writing my book and the devfest season is approaching, it is time to focus on technical talks. I have created some new talks and also updated an existing one. Most of the talks listed below are complete although some may need a little more work.
If I happen to miss your event and do not submit a talk but somehow you came across this post and interested in one of my talks just ping me!

Android and the Seven Dwarfs
This talk is about libraries and frameworks which are crucial for any project and was previously delivered in Devoxx Belgium, Devfest Silicon Valley and Android Developer Days. Below you may find the video from Devoxx version but I rewrite all the content and rebuild all the slide deck (well, except for the jokes).

Abstract: Android is a great OS and it's Java based programming environment has offered an easy learning curve, great adaptation but also brought its own pitfalls and problems.
The httpclient shipped with android is buggy and outdated, Java's programming model does not encourage developers to use separate threads for non-ui related tasks, use of anonymous inner classes for listeners create a burden and ugly code and of course this list goes on.
This talk will focus on seven great open source libraries which do fix Android's programming model, the way jquery fixes javascript. The libraries will be covered with example code, advantages, disadvantages, internals and when to use them.
#libraries #frameworks #butterknife #dagger #okhttp #volley #retrofit #greenrobot #realm

50 Shades of Android Studio
As an eclipse veteran I always dragged my foot to Android Studio. This talk is mostly based on the teaching and lessons I got while writing Expert Android Studio book. The idea is IDEs are here to help you not to torture you. Most sadicstic yet errotic talk ever :)

Abstract: After years of Eclipse experience does Android Studio inflict you pain? Don't worry! Android Studio is getting better than ever each day! Whether you are a seasoned IntelliJ developer or an Eclipse veteran, Android Studio had many hidden features and gems which can unleash your true potential. This session will cover many tips, tricks and techniques varying from shortcuts, best practices, writing gradle and intellij plugins.
#intellij #plugins #shortcuts #gradle #buildlifecycle #codesniplets

The fault in our Apps: Android Design Patterns
Who doesn't like design patterns? Well at least who doesn't pretend they like it and know it all!! But but wait a minute, are they same on android? are they already there or need to be implemented from scratch, does android offer more? This talk will convince you that they are more than fancy words and teach you how and when to use them on your little green friend.

Abstract: In 1994, the famous Gang of Four, published their book "Design Patterns: Elements of Reusable Object-Oriented Software" and since then any developer who wants to look cool and respected is obligated to use them in their daily chats. Actually it is more than that, Design Patterns are decades of collective wisdom to provide solutions for common problems in software. Android makes heavy use of design patterns both internally and at the SDK level. This talk will focus on classical GoF design patterns and how they can be implemented on Android as well as covering patterns which are specific to Android and mobile software ecosystem.
#adapter #singleton #facade #flyweight #proxy #dependencyinjection #mvc #mvp #observer #command #builder

OpenJDK for the a'N'droidlings
We, android developers, have been dreaming to use lambdas and new language features for a long time. However, moving to OpenJDK has changed more then just the language syntax but the whole internal build and debug process. Well, don't worry! this talk covers all ;)

Abstract: The day has come, finally with version N, Android moved to OpenJDK from the old rusty "Harmony" based friend. With the move to OpenJDK finally aNdroid finally has access to many new language features lambdas, streams, default methods on interfaces and many more. You have listened all those features in Java talks for years, this time come and watch  how the new language features and invoke dynamics will change your aNdroid world. 
#jack #jill #javabytecode #artbytecode #invokedynamic #openjdk

Friday, 1 July 2016

Tips for writing a book..

Tip #1, don't even start. Turn your back, walk away, mark all related emails as spam. Seriously don't underestimate the time you need to invest and believe me it is never ever worth the money. Most probably many stuff will change by the time you delivered the writings which will drive you mad. BUT worse of all, you will become addicted! Even thought you know how hard it is you will jump into another opportunity when you are finished.

Tip #2, work with the best. Book writing is not a one man job. Find a good co-author and form a good team else you will burn out yourself, spend to much time on writing which will make your already written material to become stale and outdated. My first book I was very very lucky to come across the best people I could work with. My editor Mary James supported my book proposal and later did a tremendous job to bring a co-author, Alex Theedom on board when I burned out. Although I was terrified with the idea to share my book with another author at first suddenly I realized how team work raises the quality of the output. That's why I carefully selected my co-author at the very first day of my second book. Onur Dundar did a tremendous job in keeping me up to schedule and challenging my knowledge and the quality of the output. To summarize find a good co-author who will work with you as a team.

Tip #3, find an effective way to split the work. My first book, both Alex and me (mostly) work on the same content, writing in turns and giving feedback each other. This works pretty well specially on advanced topics but happens to be slower. On my second book, we followed another strategy with Onur. Each of us (mostly) working on a separate chapter bringing it to almost complete before passing it to the other for finalizing the content and the language. This happens to be way faster but also harder to follow same style of writing and still some chapters will require both authors to work on the same content to challenge each other. So the strategy you should choose to accept heavily depends on the chemistry between the authors and content you need to deliver.

Tip #4, be patient for comments and edits. Never forget, the editors and reviewers are there to raise the quality, not to annoy you. Respond each comment and try to understand the point of view. Some comments may annoy you because a non-technical person is commenting on a very simple basic technical point like "what is an IDE, please explain each abbreviation". The last thing you should do is to get annoyed and say come'on this is a book about an IDE, if the reader doesn't know it he/she shouldn't have bought the book in the first place. The same also goes other way as technical people may comment in non technical texts such as stories. The trick to remember is everyone is in the same team and most of the reviewers and editors are much more experienced than you on writing and all they want is to raise the standards. Also be patient and calm for the comments you receive after your book is published. Try to contact and gather more feedback if someone is commenting on Amazon or any other platform.

Tip #5, make sure you are writing a book you want to read. Publishers may request high page counts or different topics to be covered and believe me they have a reason and they are not evil but you can only deliver quality content on what you know and what you want to deliver. If you are adding words or stories just to make it longer, just forget about it. If you are adding a chapter which you are not interested in writing or learning, just stop it. When I finished my first book and was writing the front matter, my co-author Alex has written a wonderful comment which summarizes the whole motivation we had. I strongly encourage everyone to follow this. Quoting Alex, "Every chapter that we wrote had the goal: write content that we would like to read ourselves". If you want to write a book, write something you want to read.

Tips #6, find a good topic. Writing a book like a "tutorial" for a framework or a platform which is already very very well documented is a waste of time. Android SDK, Hibernate. Spring are few examples of very well documented subjects. If you are going to write a book on beginning one of them, you should make a difference or even before publishing your book, their website will be more updated than your content.

Tip #7, find a good preface author. Specially someone you like to read or someone you admire can be a great foreword author. Again I was honored and very very luck to have Reza Rahman to write the foreword of my first book and Mark Allison to write the foreword of the second one. Reza was a huge influence for me with his book EJB in Action. Similarly Mark's blog has been a very good resource for my current daily work, not to mention both are great speakers on stage, Reza being JavaOne Rockstar and Mark being the magician and a GDE. Simply find someone you want to honor their name because of their work.

Tip #8, forget aggressive marketing. Best case you are getting paid a very very small percent from each sale. My first book was available on torrent even before I have seen it on paper. Use your book to get attention to your talks or work but forget about pushing people to buy it. Complaining about how much time you have invested in the book? Goto #1.