Subscribe to this blog

Follow by Email

Search This Blog

Pages

A Java dev journey to full-stack: first chapter

I am an experienced Java developer and (surprise!) I like Java. I know it is not perfect but it works just fine for me (I enjoy type-safety and I do not consider verbosity a disadvantage, quite the opposite). I also know that some people dislike Java, which is also fine.

But recently I decided to step out of my confort zone as developer, my goal isn't to be one of the "cool kids" neither trying to monetize a new skill in the job market.
I have a quite practical motivation: I want to be able to build more (different) stuff.
That's exactly the same reason why I learnt Android development by myself a couple of years ago.

Web applications are ubiquitous, even more than native mobile apps, and thanks to cloud computing, one can easily and inexpensively release their idea/app to the World Wide Web.

I already did some Web development in the past, in the bad old days of JSP and JSF, but the process was slow and painful.

Nowadays the Web landscape has totally changed though, JavaScript is a mature language, it provides classes (well, not really, but bear with me) and a whole ecosystem which includes dependency injection, dependency resolution, a backend server (Node.js) and advanced IDEs.The JavaScript Framework

So the first step was to decide what to use for frontend development, among the numerous options, there are two main ones (by popularity): React or Angular.

After some research it seemed that Angular was more suitable for devs coming from the Java world, mainly because of two reasons:
- Typescript is more strongly typed than "naked" JavaScript, which makes it more similar to Java.
- Angular is a framework (not a library like React) which means that it provides more guidance (it's opinionated) and includes a comprehensive set of helper tools (e.g., a CLI).

So I chose Angular and VSCode as my Integrated Development Environment.

The Proof Of Concept

After having decided with what I'd code, one more important question remained open: what to code.
All I knew is that I wanted to make a modern (albeit simple) single page Web site. And by modern I essentially meant asynchronous live data loading onto the UI without user interaction (i.e., server data push, no need to click the "refresh" button).

But what would be the source of the data? That's when I decided to make things more interesting by throwing Android into the mix.

I decided the application would push location updates from my phone to the backend running on AWS and then to the Web browser.
All the data transfers would be in JSON format and secured by HTTPS (self-signed certificate).
And since I was already in 'adventurous mode', I decided to use Vert.x (a Java framework to build reactive applications) in the backend because it had been on my radar for a while already and it also provides good integration with JavaScript through its SockJS event bus bridge.

You can see how the web application works in the following video:

The Code

After several weeks of after-work coding and dealing with three different Git repositories, three different IDEs (AndroidStudio, Eclipse and VSCode) and two programming languages (Java and Typescript), I am ready to share the code with anyone who would care to have a look at it:

And the first version of the application is live at https://mylocation.devaction.net
Please note that you will get "your connection is not private" warning (or some other similar one depending on your browser of choice) when accessing it because of the self-signed certificate, but as long as you check that the SHA-256 fingerprint matches the following hexadecimal digits, you are safe:
DA C1 F8 06 D2 4E 17 C9 C4 F4 D7 47 40 AF CD F1
22 00 36 3E 97 CB 41 C2 63 DD 28 1F A0 51 12 29

Also, I do not think the backend will be able to handle much load since it runs on the smallest type of Amazon Lightsail instances (just 512 MB memory and one core processor) so if it is not able to keep up with the demand at least it would mean that this post has become somewhat popular :-)

I could write much more on related topics such as:
- how I combined Vert.x and Spring in the backend
- the Android service which fetches the location provided by the GPS
- client-side certificate
- the application configuration (loading, password encryption)
- RxJS
- the Vert.x event bus SockJS bridge
- the social implications of sharing my live location with potentially everybody (spoiler alert: I introduced a "masking" security mechanism in the Android code to keep the area where I live under the radar)

But I will leave that for future chapters of this journey since this learning exercise is far from over yet, stay tuned!

Comments

Post a Comment

Popular posts from this blog

I have been interested in the shared/distributed ledger technology (a.k.a. block chain, a.k.a. the magic behind cryptocurrencies) for more than a year already but recently I had finally put real time and effort into it.

And since I believe that the best way to understand something is to get your hands dirty, that is what I have done, after I got a grasp of the core principles (or that is what I thought back then), I decided to code my own shared ledger simulator.

Initially, I also considered to look into the main existing code bases (e.g., the source code of the main/official Bitcoin client/miner or Ethereum's) since they are open source, but seeing code like thisput me off... That file is 3229 lines big!!! Plus it is written in C++.Do not get me wrong, I truly believe Satoshi Nakamoto (i.e., whoever hides behind that name) is a genius and also a great software developer, but he/she/they for sure did not have readability as their main priority.

Update from Thursday September 14th 2017: The
very same day I posted this (the day before yesterday), I realized that it looked like Google had just
made it effectively obsolete

I thought that at least I could claim that I chose a very demanded functionality to blog about, since Google decided to add a new API to provide this very same service. Even the names are quite similar, I called it "SMS Verifier" and they call it "SMS Retriever". But after looking into this new Google Services API, I found out that it requires to use a paid third-party service such as Twilio... very disappointing!So my original post (which follows below) is still relevant after all, since it allows you to verify the user's phone number for free.

Original post: Tuesday September 12th 2017It was about time for me to give back to the open source community, so I have just pushed the complete (working) code to verify the user's phone number from within an Android app to Github.

TL;DR: After being disrespected multiple times as customer by Smartwings airlines over the years, now I can finally have my little revenge by claiming 400 euros for a delayed flight. The airline sent me an insincere and pathetic apologetic email message. Apology not accepted.I have been a regular customer of Smartwings airlines for quite a long time already.It was not by choice. The reason I fly with them is because it is the only airline which flies directly from Prague (where I live) to Valencia (my hometown).Although I appreciate that they include 15 kg of check-in luggage at no extra charge, the ticket prices are quite high compared to other low-cost airlines (Wizzair and Ryanair, for example).

Also, they do not seem to care much about their customers. Several times they cancelled a flight just few days before the departure date due to "operational reasons". It would seem to me that the real reason was that they did not sale as many tickets for that flight as they expecte…