Monday, 23 April 2018

Goodbye JavaOne, you will be missed... :(

I am sad, JavaOne always had a very important place in my heart even in it'd declining years. For the last few years, it was more like an annual gathering than the technical event I learn most but still, JavaOne had a very important part in my life.

I always followed and wanted to attend JavaOne since from the early 2000s. However, being located geographically far and multiplying the costs because of getting your income in a weaker currency, stopped me for years. Early 2009, I was working in an international bank back in Istanbul, in a well paid but kind of a boring job. We were tied to vendor tied old versions of the most boring Java stack you may ever imagine. After a rough year of releasing the new version of a project, I decided to go JavaOne. Well, it wasn't a Turkish corporate culture to support employees to attend training and conferences (at least at the time..), I asked for a paid extra leave to attend JavaOne, paying all the expenses myself. Conference ticket of $1600, an Atlantic flight for $1200 and Hotel for roughly $1000, I would easily hit $4000+ cost so at least being paid for the days I am away would have been nice. Well, my manager didn't like the idea so I just quit. Yes, it was that simple, I worked long extra hours for the success of the project and didn't like the idea of not being supported. So went back to my desk, bought my JavaOne ticket, Booked my hotel and flight.

I was amazed, it was the last year Sun branded JavaOne, although the acquisition was almost complete. I stayed at the conference venue until 11pm every night to watch BoF sessions. Enjoyed every single moment, attend every session I could and regret not attending before.

A year later my brother was accompanying me for the first Oracle branded JavaOne. With his addon ticket, we had one of the most fun times we had together at JavaOne parties including the party at treasure island! The following year I was on stage! I was on the stage where I was admirably watching my Java heroes 2 years ago for the first time. Well technically not the same stage, it was not Moscone anymore but it was JavaOne!! Then again and again.

When I was getting married, the date of JavaOne was an important prerequisite to check. In fact, JavaOne became our honeymoon! About a week after getting married, we fly to San Francisco to attend JavaOne where I had four talks, with one being featured!! Well, that year I also remember for giving one the worst talk ever. Updating the source code in the morning before the talk and realizing all the demos will fail made me suffer on stage.

I had the chance to give talks with amazing people together on the very same stage. I gave a talk with my Java EE hero Reza Rahman, with my amazing friend Java Champion Mert Caliskan, my co-author and good friend Alex Theedom. In total, I attended 9 JavaOnes and gave 9 talks.

Oh, the parties... Well, except the first year which I was a rookie, I attended every party, sometimes up to 3-4 a night, and stop by a beer at the Taylor/Mason cafe.

Well, I guess it might be the time but still it is emotional. Overall the conference was in decline in the last years. Java was not the new kid on the block anymore, even worse didn't have the investment and progress it needed.

JavaOne was not just a technical event, it was a place to have my holidays, meet my friends, drink beer. It was the conference every year made me find interesting topics to give talks. It was a routine in my life. JavaOne simply changed my life,  Goodbye JavaOne, you will be missed.

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.

Tuesday, 10 November 2015

Wrap-up JavaOne'15

It might be a little late for the post but there is much to be said..

Another JavaOne is over, not only a JavaOne but 19th JavaOne on 20th year of Java!!

I just feel JavaOne is turning into a old friends gathering event for me than the technical conference it used to be. The conference is shrinking in terms of contents and number of sessions while Oracle Open World expands to sessions rooms which were part of JavaOne.

Don't get me wrong, I still enjoy going JavaOne, meeting friends and community. However, variety of sessions become much limited. The 20th year of Java keynote must have been the most boring one except for the part Scott McNealy was on screen. Actually it might have been the only worth to watch part of the whole keynote!

So what happened... why J1 is just fading away? Is java and us getting old?

It is not a secret that J1 has lost a lot of blood after being kicked out Moscone in 2010 but it got worsen with loosing the mobile track with the going down of Java ME. Since moved out of Moscone J1 was hosted in the Hotel trio Hilton, Nikko and Park55. However this the trio has become duo leaving another hotel to Oracle Open World. I really wonder if OOW need so many rooms (Moscone South/North/West and now an additional hotel!) while j1 is shrinking.
Also this year before J1, Oracle terminated contracts of many veteran Java Evangelists which left most fun part of Java and J1 in the dark. One may argue that Java does not really need evangelism anymore but than where was the fun stuff such as minority report demo at the keynote?

So what to do now? How can we bring back the spirit?

Here are my 2 cents to Oracle...

- I respect and understand you want to highlight stuff you are doing in the keynote but believe me it is boring. Either find a fun way to talk about it or just delegate this to session speakers. For the last 3 years we are just listening the same jigsaw and lambda slides and how Oracle is investing and engineering java! For the keynote, for once, forget marketing and make fun!
- Let's face it Java ME is long time dead on mobile but may re-born for IoT. This year was a good sign that Java ME can really shine with IOT but thats it.
- So Java lost the mobile phones?? No, hell no.... Even if you like it or not, Android has become the most widely used mobile OS and even if it does not run on JVM, it is still the Java language! The lawsuit is over, make peace and let Java survive on mobile! Let's face it what will happen if google walks away from java on android! Be wise Oracle, even Microsoft is investing on Android...
- Please, please, please keep j1 keynote in moscone!
- Finally, we are on the same boat Oracle... please don't just let it sink..

Tuesday, 14 July 2015

Permissions in Android M Preview

Milkyway? Well I guess so but macaroon, muffin, marsmallow are still good candidates to become the name of the new Android version. We have more to make guesses until the final version is relased in quarter 3. Following last years tradition of releasing a preview version at the time IO, Google has already released M Preview. Unlike last year this preview release pretty much functional and two more previews will be release (end june and end july) before the final version.

Let's forget about the naming and deep dive into technical parts of 'M'. If you are planning to have hands on experience on M, the system images for your devices are located here. If your android studio is subscribed the preview channel for sdk updates, you should have already been informed about an available sdk update which is called "android-MNC".

The most significant change with M is the permissions. Android applications ask for permissions before the installiation of an app. Once the app is given the permissions it is asking for, disabling a permission is not an option for the user. This was a simple design decision (both for users and developers) but introduced undesired app behavior for a user. However, on M, permissions are granted or denied at runtime.

If the permission is denied the app may receive an empty object, a null object or may even got a security exception. Since apps relied on permissions to be granted automatically until M, this would introduce an important change to legacy apps.

If you do not update you app compiled with target sdk pointing M, the application will ask for list of needed permissions at the time of install. However, the user can always turn of a granted permission which leaves the app to deal with denied permission. A dialog saying the app may crash will be shown while if user disables a permission. If you compiled your app with M as the the target sdk, the app will install silently and ask for each needed permission at the time execution.

This a big change which may effect previous code. Simply you need to revisit your old apps make sure you handle the cases where permission is not granted. In most cases the app should recover and continue working.

I think this a very good change. Users tend to not read permissions while installing (do any of you read agreements?) but asking permissions in runtime always gets the attention of the user. Plus the user would realize what current context and judge if the permissions makes sense.

Welldone Android team, let's see how old apps will survive the change..