java – alan williamson

Weekend’s Top 8 roundup – 5th Dec

First week of the last month, we see BMW locking bad people up, Apple Watch sales fall dead, Amazon legalizes shoplifting, Bluetooth gets faster, Canada gets a data center, Java 9 may slip, clues to how Samsung built a fire starter and a true legion is no longer in this world.

BMW remotely locked a thief in the car until the fuzz came
Finally a great story about why connected cars matters to everyone. Seattle Police were helped by BMW when it was reported that someone had taken the opportunity of the owners carelessness with their key vob to drive off with the car.

Unlucky for him though, it was a high-end BMW that could remotely be controlled and the car was locked from the outside, trapping the light finger bugger inside until PSA (Police Side Assistance) came!
Sales of Apple watches plunge; down 71% from last year
While we have the likes of FitBit buying up Pebble for $40M last week, we see that Apple is not having a great time of it with its range of wearables. Sales are down a whopping 71% compared to the same quarter last year.

You would think maybe the market for wearables is showing signs of weakness, but you would be wrong, everyone else’s shipping is up. Guess Apple just can’t compete with the competition/value.
Amazon Go, launches the mother of all big brother shops
Picture a futuristic shop, where you walk in, browse around looking at merchandise and then if you want it, you simply take it and as soon as you walk out the door, you are billed for.

No waiting in line, no handling of cash, no annoying bagger asking if you want your bags carried (well that bit may still be there). This is Amazon Go, a new grocery shop opening in Seattle next year. Register on your phone, then boom as soon as you walk out you are billed. It is like legal shoplifting!
It’s a go, Bluetooth 5 finally launches and it’s even more powerful
Bluetooth, the favourite short range network that connects your headphones and car to your phone (and also a great way to spam out obscene messages to anyone that tries to search for open networks).Bluetooth 5 has 4 times the range and more bandwidth, meaning you can walk further away from your phone and stream more data!

New phones will start supporting this very soon. I just want it to work from my jean pocket to my headphone, not a huge ask.
Amazon Web Services opens its first Canadian region
The world’s largest cloud provider has opened its first region north of the border, namely in Canada – you know the unofficial 51st state. The Canadian region supports all the big services of AWS and will be a boom for any company operating up there, as well as being able to keep the data out of the hands of the American government.

AWS has a huge footprint, with pretty much every major region in the world covered with a data center – Canada is a little late to the party considering how close it is.
Java 9 looks to slip release date of the July 2017
One of Java’s biggest releases to date, may be at risk of slipping a few months from its target release date of July 2017. Java 9 has many big features coming in, with one of the biggest ones Jigsaw. Jigsaw is the modular run time to make it easier to ship Java into smaller and more manageable pieces.

This one shouldn’t concern the masses at all. Java is such a key component of our eco-system it is vital they get it right, not get it on time.
Clues are emerging on why the Samsung kept catching fire
A manufacturing company has made a claim that the Note 7’s internal layout and design maybe fundamentally flawed as it has attempted to cram too much into a small space and not left the usual 10% gap between battery. Thus when compressed, for example, by heat expansion or someone’s fat arse sitting on the phone, two points touch that shouldn’t be touched, and boom!

It is yet to be seen whether Samsung will ever officially release a reason as to why its flagship phone burst into flames. But until then, this is the most credible scientific one to date.
A true space hero dies, John Glenn departs this world for the last time
John Glenn, a pioneer of the space race, has sadly died this week at the ripe old age of 95 years. Glenn was the first American to fully orbit the earth, and also, the oldest many to travel to space at 77 years.

But his notable records aside, Glenn was part of that era that took humans off this planet and gave us the inspiration and stepping stone to explore further. This generation of people, hold a very dear place in my heart.

… and this week’s soundtrack is dedicated to the excellent HBO’s Westworld that officially ended its first season run this week. Every so often a TV show comes along that is so well written, produced and acted that each episode is simply a piece of art to be enjoyed. If you haven’t watched it yet, then please treat yourself. Now for the bad news- season 2 won’t be here until 2018.

Working with the SalesForce REST API

Quick overview and guide to working with the SalesForce REST API.

Historically anytime I have ever had to interface with SalesForce, I have utilized their SOAP API. SOAP is a horrible nasty piece of technology that puts way more overhead on communications than is really required. Handling SOAP within Java is an even more pain in the ass as you wrestle with WSDL’s to create/compile your local representations of objects. Fortunately there is now a much easier way and for my latest project I got an excuse to take it for a proper spin.

SalesForce offers an alternative to its SOAP API and that is the lightweight REST API, with JSON packets flying back and forth chewing up the minimal of bandwidth. I can attest that it is an absolute joy to use.

For anyone that is aspiring to cast aside the chains of SOAP (which I will call the old days) and move to a lighter world I offer the following to help you along the way. All the source code is available on my Github page. I have written a small Java wrapper class that makes interacting with the REST API extremely easy, including re authenticating the token if a call fails.

1. Configure SalesForce

In the old days you accessed the SOAP API with a username and password. In the REST world the initial authentication is a little more complicated. SalesForce uses OAUTH2.0 to secure incoming requests. Fortunately they use a number different mechanisms within OAUTH2.0 but I am going to focus on the Username-Password method – which basically involves making a call to a given endpoint and retrieving a token to which all subsequent requests will be validated against.

However, before you do that, you must first register your application with your SalesForce instance. When you make your API calls it is this app that the calls will belong to and you can set the various security rights etc at an app level.

Login to your SalesForce account and then navigate to the ‘Setup’ area and look for the ‘Build’ area, and select the ‘Apps’ from the Create menu.

Within the ‘Connected Apps’ panel, click the [New] button and you will be presented with the following form to fill out. It looks a little frightening at first blush but there isn’t a huge amount of data required here.

Give your application a name, something you will know, and a Contact Email address. Now since we are using the Username-Password method, we don’t have a lot of fields to fill out there. You do want to click the ‘Enable OAuth Settings’ checkbox, and in the ‘Callback URL’ simply add https://login.salesforce.com. Next you will choose the security roles to which your app will belong to. This can change at a later date, but select ‘Full access’ to begin with, which gives your app the same level of access your traditional SOAP API had.

Then save out the form and you are nearly done. There is a couple of pieces of information you need to grab. Once saved, it will be displayed in your list of connected apps, click the [Manage] button.

For retrieving the API session token, you need additional information, which is the ‘Consumer Key‘ and the ‘Consumer Secret‘. Take a note of these two values as you will need them later.

2. Retrieving your session token

To retrieve your session token you need to make an HTTP POST to the https://login.salesforce.com/services/oauth2/token endpoint. Good news, this is the only time you will hard code a URL to SalesForce – from here on in, all the URL’s that required will be told to you over the wire. You need 5 pieces of information:

grant_type
password
username
<one of your salesforce users>
password
<their password><their access token>
client_id
<the consumer key from the connected app>
client_secret
<the consumer secret from the connected app>

Assuming you have setup everything correctly then you should get the following JSON block back. If you are not successful then SalesForce is very good with its error and status responses so you should be able to quickly resolve any issue.

This block has everything you need in it to interact with their API endpoints. The session will time out (response code 401) so you just have to call this login process again to retrieve a new token.

An important piece here is the host name for your company described in the ‘instance_url‘ key. This will be the root URL of all your REST calls.

You can see the Java code, doSessionExecution(), for this here at my Github repository.

3. Authenticating requests

Once you have your token you need to add in the ‘Authorization’ header to all HTTP calls with the token_type and the access_token. Using the session block retrieved in the previous section we would create our authorization as follows:

In my Java code, getAuthorization(), I simply pull out the two keys from my HashMap and concatenate them together.

We are nearly ready to start making calls to the API. However, there is one small step that will make life a lot easier – a quick introspection of your company’s objects to determine all their endpoints.

4. Introspecting your objects

SalesForce will return a list of all your objects and their corresponding high-level properties including the REST URL’s to which you can perform operations with. This callback does not include all the field properties for the object, there is another call for that, SObject Describe.

A JSON packet is returned with all your objects listed. Here is a snippet from that return block highlighting the standard ‘Account‘ object. Notice the ‘urls‘ inner object detailing all the endpoints we will use for interacting with our object.

In my Java code, doDescribeObjects(), I pull these objects out from their original JSON array and put them in a HashMap keyed on the object name for faster retrieval at a later date.

Now we have everything we need to interact with the API minimizing the amount of hard coded URL’s we have in our application to a single one; the initial login one.

5. Retrieving an object

Retrieving the value of an object, we just need its 15 character Id (yes only the short version of the Id, not the previous quirk of the 18 character Id) and the endpoint for that given object. We perform an HTTP GET on that URL appending the Id. So the raw HTTP header call to https://na30.salesforce.com would be:

This returns back a JSON object representing the current value of that SalesForce object. If you look at my Java code, get( String object, String id ), you can see where I create the URL from the instance_url from our original login request, and then using the URI from the describe objects call earlier.

6. Updating, Creating and Deleting objects

To update, create or delete an object you can use the same URL you created in section 5 but change the HTTP method type.

PATCH
For updating an existing object
POST
For creating a brand new object
DELETE
For deleting a previous object

A small tip, if your underlying HTTP library does not offer convenient access to a given HTTP method you can use the POST method and add the query parameter ‘?_HttpMethod=PATCH‘ to the end of it. Nice touch SalesForce!

7. Misc. endpoints

There are many different endpoints you can choose to interact with, that will span across multiple objects. For example you have query objects, get the last updated objects, the latest objects deleted. The API is extremely well covered and more importantly documented very extensively.

Each API call needs to be authorized, which you do the exact same thing as detailed here. All you need to know now, is which API endpoint to call and how to interact with the data returned.

8. API Limits

SalesForce limits its use of the API (which interestingly enough you can determine what your limits are through an API call – assuming you have credit left!). You can read about the limits here, but the key to remember is to not hit the API too quickly in quick succession. That will result in you getting denied for a little while.

However, there is an easy way to determine how much you are currently using within your allocated daily limit. Each API request, returns the Sforce-Limit-Info header that details just how much you have chewed up thus far as an organization.

I hope this has helped you with the SalesForce REST API, especially if you are coming from the SOAP world.

SalesForce has its place in the corporate landscape and given its size and reach, the company isn’t going away anytime soon. Working and integrating SalesForce into your applications is significantly easier than it was in the SOAP days with their REST API.

JavaScript is our new Visual Basic

JavaScript is sweeping the development community and is popping up everywhere, having broken free from the confines of the browser. We see it at the server side, embedded inside programs, powering mobile apps and we even see it popping up inside of games. However, we are creating a huge headache for developers and companies in the future, because JavaScript was never designed to take on this scale. It isn’t a proper language.

Now that I have your attention let me begin.

JavaScript burst onto the scene back in 1995, when Netscape released it as LiveScript. It was quickly renamed to JavaScript with a shorted sighted view of hooking into the popularity of the other new language at the time, Java. The name stuck and nearly 20 years later, is still proving to be a constant source of confusion for beginners, managers and recruiters.

Java is a fully typed, compilable language, whereas JavaScript is a dynamic, scriptable language. They both have Java in their name, but there-in the similarities end. They are no more alike than C++ is to Ruby.

JavaScript is a beautifully powerful simple language. There is absolutely no barrier to develop solutions with it. No compilation, no fancy deployment phase, just save the file and hit refresh/reload and by’n’large you are good to go.

For the most part JavaScript is absolutely fine, sprinkled into web sites to create a much richer experience to the application. If it was just limited to that, then there wouldn’t be so much of a problem. The problems come when you attempt to do anything large and complex with JavaScript. The code becomes quickly unmanageable.

The language itself does not impose any sort of standard for code creation. You can have everything in one big file if you want, or even in one long line if you really are perverted. There is no official way to create objects, instead a pattern is semi agreed on to be adhere to – “More honoured in the breach than in the observance”.

There is no type checking going on to make sure what you are about to call is indeed still there and is still expecting the type of data you are about to pass to it. You can’t be assured of what type of data is coming back, it could be anything.

Scaling JavaScript up beyond a single developer starts to show its weaknesses. No one likes to go into JavaScript code to start enhancing or fixing. The opportunity to break existing functionality is huge, and here is the kicker, you won’t know it until that particular line of code gets triggered by the application. A single stray semi-colon can bring down a complete system.

This is an intolerable situation for the enterprise. The code the enterprise produces has a long shelf life compared to the code of startups and most web sites. Many developers will cycle in and out of the project/company and this code needs to be maintained, added to and ultimately supported for many years to come.

There are huge amounts of work being done in this space to start to get a handle on this problem. Many projects are popping up to give JavaScript, type checking, mock compilation, function look ups to try and get ahead of these fundamental problems.

Yet that isn’t enough.

JavaScript has another problem lurking in the background which is potentially even more serious. Because the barrier to entry is next to nonexistent, anyone can dabble in JavaScript. Literally anyone.

It look’s so easy, that non-software developers who have not trained and have a deep understanding of the cause and effect of software design are producing large projects under the illusion that everything is working beautifully. Their lack of discipline coupled with the loose structure of JavaScript is a recipe for disaster when it comes to writing code for maintainability and longevity.

“JavaScript makes it easy for anyone to write vast amounts of monstrously unreadable, undebuggable, impenetrable code.”
Ken Scott – Answer at Quora

We’ve seen this before.

1991 was the year Visual Basic burst onto the scene from Microsoft. This powerful drag’n’drop programming didn’t even start out as a true language, but Microsoft decided to add Basic to the company it bought, Tripod, to which Visual Basic then became. Visual Basic revolutionized the computing landscape, and while it was officially retired in 2005, it’s legacy is still powering a vast array of crucial applications and corporate tools world wide today.

What Visual Basic did was to let anyone build complex applications by simply drawing on a canvas, tying components together and before you knew it, you had frontends to databases and systems quickly evolving. Everyone got in on the act. From the spikey hair boss, who fancied himself a developer, to the youngsters in their bedroom, Microsoft made it really easy to do great things.

That is no bad thing, however, what it did, was to create huge amounts of legacy spaghetti code that goes largely unsupported. While you may have a VB app running away, it is slowly eroding as no one wants to crack open the source and start making changes. It was code that was hacked together by those that didn’t really know the techniques of the trade. Microsoft convinced legions of companies that real software engineers weren’t needed, and if it couldn’t be done in Visual Basic then it wasn’t worth doing.

Microsoft was not alone as others got in on the act too. PowerBuilder, Delphi, Paradox are ones that spring to mind that had a similar drag’n’drop concept.

JavaScript I contend is even worse than Visual Basic in the legacy it is producing for us in the future. The applications written with JavaScript are far more fragile than the VB apps that were produced with a few clicks and drags of a mouse.

JavaScript isn’t going anywhere soon, if anything, it is spreading further and wider.

So what is the answer?

I don’t believe the answer lies in tooling. Tooling will only help the situation, but anyone with a text editor can easily bypass any rules or laws the tooling is hoping to enforce. Discipline and code review in following the guidelines and laws set out by companies will get you only so far too.

The answer I believe lies in looking at JavaScript not as a language, but instead as a runtime, an instruction set if you will. What if we view JavaScript’s syntax as the bytecode of a virtual machine, with that bytecode being produced by a compiler, from a language that supports and enforces strong type/function checking.

There is a reason why very few people write actual machine assembly language these days – it is too darn complicated and prone to easy mistakes. It has a very loose structure too, with complete power to do anything in the system. You can’t get much closer to the CPU. However, assembly is not the language you want teams of developers producing. It is too low-level.

JavaScript should be treated with the same respect as assembly. It is a truly wonderful runtime, that has democratized the differences in computing platforms by providing a virtual machine that has a known set of characteristics and behavior. However, JavaScript is just too dangerous and powerful to be put in the hands of most developers. It is too easy to make colossal mistakes that could cost large amounts of money and now it is going to embedded devices, lives.

Instead let us use a strongly typed, object oriented language that can compile down to JavaScript. This allows us to utilise all the compile checking that goes on well before we have to execute a single line of code. No one has to touch JavaScript code directly again. The tools support for these type of languages far out passes anything that can be provided for such a loosely coupled language such as JavaScript.

I am not alone in my thinking here. Google has been producing JavaScript with its GWT project for over 7 years now. Now JavaScript has reached mainstream, GWT is gaining popularity and a renewed interest. GWT allows you to code your web applications in Java, with all the usual checks and balances that any Java application brings. But instead of distributing .class files, GWT takes those .class files and creates JavaScript code that can then be shipped to the browser for execution.

GWT isn’t the only horse in the race, there are other projects that attempting to use Java as the source with JavaScript as the output.

I would much prefer to have a team of developers support 1 million lines of Java code than 1 million lines of JavaScript code. I also get the advantage of future compiler optimizations free of charge. The Java-2-JavaScript compiler can evolve and produce faster and smaller code at a completely different rate than the top level application. I don’t have to change any of my application code to take advantage of this.

JavaScript is a powerful language that has enabled some beautiful applications to exist. I believe it has a huge role to play in our computing space as we evolve to build better and greater solutions to our problems. But let us not get caught up in the hype and produce unmaintainable code for generations to come to have to support.

Let us instead see JavaScript for what it has done, which is to give us a truly virtual platform to run our logic upon, whether it is a browser, mobile device, embedded or the server side. Leave the actual production of JavaScript to highly optimized compilers/convertors that can do far better than a human, while removing the headache that a loosely typed language brings to the developer.

Who knows, we may actually put the Java back into the meaning of JavaScript after years of confusion and misrepresentation.

References

JavaOne 2014 App – the anti-pattern to mobile development

The JavaOne conference, held annually in San Francisco is a shining beacon of everything good and wonderful in the Java space. What was once the main event, JavaOne is now a side show to the massively large OracleOpenWorld, which takes over all of the Moscone halls, streets and a number of hotels. There was a time JavaOne was that big – but Java has fallen and if this years conference app is any indication, then we have much to rebuild. More on that in an upcoming blog post.

There is a huge amount of sessions to choose from, lots of rich content and spread over 5 days you want to get the most out of it. Perfect opportunity to install a mobile application to help pick, schedule and even rate the sessions. An app that was in your pocket never being too far away from everything you need to make the most out of this unique experience.

Freely available from the app store, installation was relatively straight forward. I say “relatively” because, the first thing the app does when it boots up is to download an update for itself, inside the app! That isn’t the usual app design pattern. But wait the crimes-against-app just get better.

On the first blush, the app runs up (very sluggish I will say, even though I am on a Samsung S5 and full bars on 4G) and asks for your username and password. A pain, but Oracle needs to know who you are so they can sync up your schedule. No problems, a common pattern here for any app to ask you to login. A once pain to endue you would think. Not on the JavaOne app. Oh no, this bad boy will ask you at least once a day, if not more. I don’t know about you, but I don’t know my passwords, I outsource that to LastPass. So typing that big long obscure password in multiple times has already raised my annoyance factor big time.

The app displays all your schedule, in a standard looking mobile view. Scrolling done with the usual swipe actions. Again, feels very sluggish, feels like this is a web page being rendered instead of the instant feedback you get from a local app. Hitting a session, takes a good 1-2 seconds before its displayed.

Once the session has loaded, all the content is there. But again, look closely the app doesn’t feel native. It feels like a rendered page with the tabs etc just feeling a little off. Clicking on the tabs, takes another 1-2 seconds before the content is loaded up.

No matter what you do really, you are greeted with the waiting feedback, and you see your network icon showing that data is being moved around somewhere. The app feels like a very thin layer to an HTML site. That is not what we demand from an app from the worlds largest software company aimed at the very demographic that is there to design and build the next generation of software.

As I noted before, the app crashes a lot. I mean a lot. So maybe this isn’t an HTML facade, but just a poorly design and built app. As a user you get to know which areas you stay away from because when it does crash, you guessed it, you have to run it up, wait for the updates, login again and navigate yourself to the app. Ridiculous.

The app is a train wreck. Sucking away your battery, continually crashing, slow, poor rendered content, continually notifying you it has updated, the app is the perfect anti-pattern for mobile development.

A huge wasted opportunity to really show that Java and Oracle were back at the forefront of cutting edge technology and demonstrate that even though Java celebrates its 20th year next year, there is still life in this young dog yet.

This app was cutting edge 5 years ago. Even then, only to those that see past the issues and marvel what could be when it evolves past the point of a proof-of-concept. This app shouldn’t even get the alpha tag assigned to it, let alone released to the community at large.

JaveOne is a great conference, just don’t rely on the app to help you navigate it all.