Thank you for visiting! If you liked the site, please add a bookmark, else add a critical comment! Would you like to visit Greece? Traditional Greek flag This real estate site is only available in Greek! The holy mountain

Friday 4 May 2018

Comments on Cloud Native Java: Designing Resilient Systems with Spring Boot, Spring Cloud, and Cloud Foundry

As the title says the authors emphasizes on proprietary open source technologies based on Spring Boot and Java 1.8. The  huge text assumes an advanced reader who  not only has solid experience in several Cloud computing  vendors, namely Amazon web services,   but also in Spring, REST web services, integration and design architecture. This is clearly not a book for introductory level java programmers wishing to learn Spring or Java, although there is a guide about setting up the relevant IDE and so on. I quote the contents of the text at a glance:
  • The Basics: learn the motivations behind cloud native thinking; configure and test a Spring Boot application; and move your legacy application to the cloud
  • Web Services: build HTTP and RESTful services with Spring; route requests in your distributed system; and build edge services closer to the data
  • Data Integration: manage your data with Spring Data, and integrate distributed services with Spring’s support for event-driven, messaging-centric architectures
  • Production: make your system observable; use service brokers to connect stateful services; and understand the big ideas behind continuous delivery
On the bright side, the code snippets presented in the text are coloured, making it easier to grasp it gist, and pleasant to the eye. Although the authors favour the open source movement, there is plenty of criticism i.e. on microservices architecture drawbacks, mainly due to overuse or misuse.
On the dark side there is a long list of errata on the publishers site, which at the time of reading the book was still unconfirmed.
All in all the book offers an enormous amount of useful information, but in my opinion still lacks of some more official after sales support by the authors.

Friday 26 January 2018

Comments on Beginning serverless computing, by M.Stiegler, APress

On the bright side the book is well organized, written in American English and presents a neat introduction to the three most popular cloud providers Amazon Web Services, Azure and Google Cloud. Although Heroku is not presented, but only mentioned once,  neither IBM nor Oracle cloud is even mentioned at all, as if they did not exist... Rainy days for both Oracle cloud and IBM? I only hope that the experts of Sun  can develop a solution which is capable of weather (or even  climate) modification of  the cloud business landscape, or  better cloudscape. After all their motto has always been "the network is the computer", or not?
 Coming back to the book, the language used to create the sample apps is exclusively Typescript, a stricter version of JavaScript, Visual studio code is the IDE used, along with Kudu, Node, the Serverless Framework for deployment, Mongo DB as NoSQL Database, Postman for testing and GitHub for versioning among others. Prior knowledge of all Rest & Json technologies is assumed, since there is almost no introduction to any, but short descriptions.
On the dark side, the use cases of the applications presented are so simple, that the code of the book is scarcely reusable. The code is at the moment oddly not available online on the publisher's site, but on Github.
All in all, the author develops a hotel room service order app in each cloud provider, comparing the different terminologies, data stores and costs, warning about possible traps, which might strip your bank account some hefty amounts of money. By the way always keep in mind that opening a personal, not a company, account for learning cloud development sometimes requires giving access to your personal banking  details such as your debit  or credit card number. At the last chapter an agnostic method of development  is  presented.  The text addresses several issues, such as vendor lock in, but the security issues i.e. of guarding online database data is in my opinion not addressed widely enough.

Monday 29 May 2017

Netbeans 8: Setting up the current java development kit

This new post addresses another repetitive task which draws the attention of a Java developer, as the time goes by and newer versions of the jdk become available for the public. That is updating the Netbeans IDE with the most current version by editing the file:

 "C:\PathtoProgramFiles\NetBeans 8.1\etc\netbeans.conf"

Although the IDE is smart enough to locate an existing jdk, every time it starts, it stalls and shows this message.



A sample netbeans.conf file follows below  for  your reference.

# Default locations of userdir and cachedir:
# (http://wiki.netbeans.org/FaqWhatIsUserdir)
#
# On Windows ${DEFAULT_USERDIR_ROOT} will be replaced by the launcher
# with "<AppData>\NetBeans" where <AppData> is user's
# value of "AppData" key in Windows Registry under
# "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders"
# and ${DEFAULT_CACHEDIR_ROOT} will be replaced by the launcher
# with "<Local AppData>\NetBeans\Cache" where <Local AppData> is user's
# value of "Local AppData" key in Windows Registry under
# "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders"
#
# On Mac ${DEFAULT_USERDIR_ROOT} will be replaced by the launcher
# with "~/Library/Application Support/NetBeans" and
# ${DEFAULT_CACHEDIR_ROOT} with "~/Library/Caches/NetBeans"
#
# On other systems ${DEFAULT_USERDIR_ROOT} will be replaced by the launcher
# with "~/.netbeans" and ${DEFAULT_CACHEDIR_ROOT} with "~/.cache/netbeans"
#
# You can also use ${HOME} variable which will be replaced with
# user.home JVM system property value. This variable is valid only in
# netbeans_default_userdir and netbeans_default_cachedir properties.
#
# NOTE: If you specify a non-default userdir path on command line
# (--userdir option) and don't specify a cachedir path (--cachedir option),
# cachedir will be in "<userdir>/var/cache".
#
# Cachedir must be different from userdir. The same cachedir and userdir
# would cause problems.
#
netbeans_default_userdir="${DEFAULT_USERDIR_ROOT}/8.1"
netbeans_default_cachedir="${DEFAULT_CACHEDIR_ROOT}/8.1"

# Options used by NetBeans launcher by default:
# (can be overridden by explicit command line switches)
#
# Note that default -Xmx is selected for you automatically.
# You can find these values in var/log/messages.log file in your userdir.
# The automatically selected value can be overridden by specifying -J-Xmx
# here or on the command line.
#
# If you specify the heap size explicitly, you may also want to enable
# Concurrent Mark & Sweep garbage collector.
# (see http://wiki.netbeans.org/FaqGCPauses)
#
netbeans_default_options="-J-client -J-Xss2m -J-Xms32m
 -J-Dapple.laf.useScreenMenuBar=true -J-Dapple.awt.graphics.UseQuartz=true
 -J-Dsun.java2d.noddraw=true -J-Dsun.java2d.dpiaware=true 
-J-Dsun.zip.disableMemoryMapping=true"

# Default location of JDK:
# (set by installer or commented out if launcher should decide)
#
# It can be overridden on command line by using --jdkhome <dir>
# Be careful when changing jdkhome.
# There are two NetBeans launchers for Windows (32-bit and 64-bit) and
# installer points to one of those in the NetBeans application shortcut
# based on the Java version selected at installation time.
#
netbeans_jdkhome="C:\PathToJava\jdk1.8.0_131"

# Additional module clusters:
# using ${path.separator} (';' on Windows or ':' on Unix):
#
#netbeans_extraclusters="/absolute/path/to/cluster1:/absolute/path/to/cluster2"