As you might know, Google I/O 2016 started on the 18th of May. Being one of the biggest tech companies in the world, a lot is expected from Google and so far I've heard nothing but great proposals.

In this blog I'll mostly focus on MR (Mixed Reality) and VR (Virtual Reality) tech. HTC launched the HTC Vive on the 5th of April 2016. HTC Vive is a VR setup for the size of a whole room. It is quite extraordinary and surprising compared to my initial understanding of VR in general.

As per all new technologies, it takes time for them to show their true power. VR in it's current state today is nothing compared to what it will most likely be in the next decade, a lot more compact and limitless. With that said, ideas raised in this blog are no more than concepts which may become realities in the future.

When I first heard about VR a few years ago I didn't really understand its power and really, I don't right now seeing as I've yet to get my hands on a headset. To me, the concept was merely an attached display to your head making the experience closer and isolated from your physical surroundings. Then, I started seeing the human user becoming the controller and that began to open my eyes towards the technology.

At this point in time, the HTC Vive costs £689 ($1000) which is quite expensive in my opinion, but it is new technology and the waters are uncharted so there's a lot of exploring to do. You end up buying the gear. Now you have to worry about the space to set the thing up, which in my case is impossible as I've barely any room to move around in my flat as it is. So there are a few limitations already, but we've only just begun the journey of digitalised realities. Something I've yet to gather is the durability of the equipment itself, how long should I expect my new £700 gear to last? The headset itself uses OLED as opposed to LED, which is known to be a lot more durable and generates close to no heat which makes it comfortable and safer for the user to interact with at such close distances.

In years to come I expect the gear to be no more than a headset and possibly a bracelet or two which renders it seamless to the user. With that I expect to see some good and bad outcomes. My prediction is that wearing a headset in public will become the norm soon after its advancement. Furthermore, wearing the headset in public will be advertised as a means of entertaining yourself "to make those long commute times fly by". As it currently stands, there's a major problem in the world with people being overly attached to their mobile phones, and speaking from a similar experience it does create a barrier from the real world. Where people used to socialise on the tube, people will instead use their headsets to kill time.

Last year Microsoft announced their HoloLens MR headset which captures the view of the wearer and renders objects on top of real world analysed objects based on all the given variables. Unlike VR, the MR HoloLens doesn't actually completely block your vision, but it is important to keep in mind they are both very different technologies and the only thing they have in common is being a wearable headset that renders digitalised data to the wearer. I personally think MR will become a lot more fitting for portable usability as opposed to VR as the MR consumer may consider wearing the headset at all times as yet another accessory to leave the house with.

To go back to Google I/O 2016, I haven't followed the entire event online, but I've read some headlines and watched some videos. In the MR department I saw some cool things such as true real-time tracking which The Android Wear 2.0 has really caught my eye. There are quite a few Google watches, but the average price range is around £220-£300 ($320-$440).

Me personally, I don't see myself buying a smartwatch for a while as my use for them is non-existent. However, I can see them being extremely useful for people who are active and move around a lot more often than I do, or who just have full hands. For example, a delivery guy, a chef, and hopefully no one driving any vehicles :head_bandage:.

Digital headsets are a pretty neat idea, but as mentioned before they can be quite needy when it comes to the space it requires and the usability. My one immediate thought regarding this is, if smartwatches begin to become a necessity, then we might see the smartwatch become a major player when it comes to headset usage as the smartwatch will be on the person at all times.

The marketing possibilities are pretty much endless. You will also have companies selling their set of digital technologies: A watch, a phone, and a headset all for the price of £999. People will buy in because it'll be the convenient option. Hopefully then we can actually have a lot more compatible software writing. One can hope.

It is important to note that in our day and age new technology practically runs off each other. You have the new Android Wear which uses Android, but so does the already existing Android smartphones. New tech shapes in the form of existing ones in one way or another in order to reach out to all their targeted consumers and ensure a working product.

What do you think about headsets and the golden future they will uncover?

TL;DR: smartwatches and digital headsets being the norm in a decade?

:heart:

Computer code plays an important role in our every day lives. To some, code would be the equivalent of a spy, it's right in front of them but they're just unaware of its existence. However, in order to maintain order and peace between nations of angry coders, software developers must unite and learn to agree to at least some standards in order to make a certain piece of code, preferably whole projects, readable.

Depending on the computer language, different code styles are used to maintain an understanding between multiple parties when reading code. This, however, is not required of one coder but failure to follow a consistent style might lead to their isolation from developers, especially if they're picky, which is something very common in the code-writing community.

I wanted to write this blog based on a recent experience I had with a project's codestyle. The codestyle required that all non-static method calls require this to prefix the method call, so instead of:

myReplacingMethod("String");

One would write:

this.myReplacingMethod("String");

I personally think it is flawed, but I'm more interested in what the public has to say about it.

I tried looking around but I've found no one to follow this code style. The argument that was made for this codestyle is that it further expresses the method call, by stating that it does in fact belong to this class, its superclass, or one of its superinterfaces. Now in some languages this might be neat and definitely expressive, but with respect, this is Java.

It has been argued that your mind will immediately scan this and ignore it, however true it may be, it will still cause the line of code to grow longer:

this.doUpdate(this.format(data));

As opposed to:

doUpdate(format(data));

The longer the line of code the more the reader will have to unnecessarily read, eventually having to go through the effort of moving their eyes to focus on reading on an average size text viewer like GitHub's code viewer.

It has also been argued that the explicitness is an advantage when dealing with static method imports. :fearful: My immediate response to this is that you don't use static method imports unless the method is being used more than enough times that it would help if the owning class name was removed. For example, a StringUtils class that calls String.format() frequently enough that it would be convenient to read and write code by statically importing and removing the owning class name. format() as opposed to String.format();.

I'm all for readability outside of IDEs, but I think that using this to further express the location of the method is just extra clutter as it is always immediately obvious whether the method is statically imported or residing in the class' hierarchy.

With that said, this has nothing to do with fields referencing, fields and methods are two very different things and should not be compared. Always use this when referring to class fields to make it both readable inside and outside IDEs.

TL;DR :-1: this.methodName() in Java as it adds clutter, but always use it with fields.

Yesterday in college, I presented a seminar about 'The level of knowledge teenagers and young adults have with programming or instructing computers to do things'. In this presentation I said aloud "I believe programming will become second nature in years to come", maybe a decade. Although it was not planned beforehand, really the whole presentation was kind of on the spot, it is something that has been on my mind for quite some time now.

First of all, I'd like for you to read the following blog by CodingHorror AFTER you read this one: http://blog.codinghorror.com/please-dont-learn-to-code/. If you've already read it, please disregard that post, as it is completely different in the perspective Jeff Atwood aka CodingHorror presents. With that said, Jeff's post is very valid.

Before I discuss my reasoning, you must first really think about what coding is. To those who are ignorant of the definition of code, the verb code means to 'Convert (the words of a message) into a code so as to convey a secret meaning' according to Oxford Dictionaries. In computing, usually we're not really trying to hide the meaning of the computer code, but the definition is still valid in that the code you usually write is through a computer language such as C++ or HTML which is eventually translated into machine code in order for computers to universally understand.

Every day a lot of code is written and produced that feature functionality users can use in some way or another. This code is typically a computer language, such as C++ or HTML. To even begin writing such code one must learn the language they're writing in. That requires both time, effort, and of course motivation, an interest. To a programmer, picking up a new computer language is sort of like learning the Finnish language as a Swedish person, very similar dialect. However, first timers can be in deep trouble for months before they learn and understand code they are reading.

That's just not ideal for arming everyone with the ability to code, not everyone has an interest in going out of their way to learn to write code. We need a way to present a way of writing code in a way they already understand. Like their mother tongue. In English I would write or say something like "Wake me up at 6AM" and it would set an alarm for 6AM. What might be going through your minds is that such technology already exists with Apple's Siri or Samsung's Galaxy. However, it's limited in what it can do and isn't accessible in a universal way, the way machine code is.

What I'm proposing is a general API present in all applications that adds immediate support for user coding that is standardised. A new way of coding that makes people's life so much more convenient because they get to change the way an application works using some words that generate a final command for the application to obey.

The reason this would be such a great investment is because everyone would feel and be in control of their own application usage. Take for example an application like Facebook or Reddit, the user hates the white background because it destroys their eyes, and lowering the phone brightness makes text unreadable. The user wants the background to be a darker colour: They command "Darken background" and the main background of the application darkens.

Another example, you're a busy business man who has many meetings per week, your smartphone has Calendar and Alarm Clock applications that you use for daily updates regarding your meetings. Typically you'd go to Calendar and specify your meeting date, but now you want daily or even hourly push notifications to let you remind you of your next meetings. So you specify the reminders every meeting you setup, that can be quite a hassle setting up all your reminders. The issue isn't quite present yet, the application would implement some template engine for your problem of setting reminders per type of calendar event.

However, the issue lies in the application developers implementing such a system. The system is independent and known only to that application. This idea provides a general way for users to be able to have two applications interconnect with each other. Although, the issue still isn't fully present. The application will implement an API that is accessible by others.

This is where the issue comes in: every application creates their own API, and every other application has to worry about implementing support for the other applications, it's a lot of unnecessary man hours.

Going back to the business man example, to immediately set up your meetings template, you would go to Alarm Clock specify a template called Meeting with some time templates set, maybe even do it all via voice "New Meeting Template daily reminders at 8AM and one hour before." Let's break that message down, first of all "New Template" specifies that we're creating a new template, with Meeting being the noun, "daily reminders" indicates the user wants this object to trigger on a daily basis at the following time "at 8AM", "and" is present so add another time to the daily basis 'time set' and read the following time "one hour before". The last part of the sentence is actually a lot less complex than you might think, simply part of this general API is variables everywhere. Part of the reason features aren't always present in applications is the amount of time it takes to make those features happen. So having data accessible via this user saves time for developers.

Then, in the Calendar application, the user would command "New Meeting 'with John'". This command will simply check out for any specific objects that go by the name Meeting and pass it some data 'with John'. Where the general API may even go a step further to further identify John and give you, the business man, more context.

What I want programmers to think about is nothing regarding how to break that order down. Instead pass it through some controllers and the application will get some responses regarding the order for the application to process, where everything follows a general API known to all.

Speaking of such an idea today is laughable because one cannot simply make everyone use such an API in a general way, which is why it will take more than one or a few people to perform such a life changing task.

The first step to making this present in all applications is providing it everywhere. This means that all platforms would ship this API as part of the bundle. Meaning large Fortune 500 companies would need to dip in and get involved in the process.

The idea itself is actually common in today's programming age, it is nothing extraordinary, all this idea presents is a general way that all software should be accessible. Doing this will greatly reward the market of smartphone users and maybe even all computer users by giving them control of the applications they use.

It is important to note that this idea is not meant to be forced upon the user, but provided optionally to them with their own consent and usage. This in itself is a major problem that all applications face today. There's one fixed User eXperience present in the application with an unexpected and unpredictable range of configuration that the application needs to specify and manage for the user.

This whole idea gives the user access to dynamic configuration where they start defining the configuration themselves. If that sounds complex for the user, it really is no more complex than commanding "New Meeting with John".

I see this feature as being inevitable, organisations can only keep going their own separate ways for so long before they get together and implement the great feature that is understood universally because in the end it is great for their own product and market.

"Coding is no more important to learn than Plumbing." Why you're very wrong. Despite the fact that these are two are very different things completely, they relate in basic human knowledge. Everyone is a plumber in that they know how to unclog a toilet by operating a plunger. Similarly, everyone should be a coder in that they know how to write very basic code.

"Would this still be coding?" Technically, yes. Although not the type of coding we're familiar with today. The idea of commanding although in plain english, is still technically specifying a code for the device to follow and obey which is then translated into machine code.

"How much effort would this require to incorporate everywhere?" A LOT. This idea of coding becoming second nature to the average human being means that the thing must be present in most places the human will come across. In this case most places is basically electronic devices, this requires the effort of all big players in the scene of electronic devices.

Performance issues Hah! Nice one.

But, why? Why not?

TL;DR We need a universal computer coding language that everyone can understand and write in using knowledge that they already have, such as their mother tongue, which is the easiest, most expressive way of reaching the goal.

:heart:

Minecraft has (apparently) made plans for supporting username changes for a while. While this change is going to make a lot of the Minecraft community's life easier, it really is a big pain in the ass for developers, I'll talk a little more about this later. Sk89q made a great post about this which you can find here.

I personally think this system could have been done better by replacing UUIDs with account names which the user will pick themselves. Of course those account names would be unique just like the current 1.7 and older version usernames are. I'm not entirely sure why Minecraft didn't implement it like this, but I'm hoping they have a good reason. With the UUID change, life is really going to be hard for developers.

Lets say you are in-game, and trying to check out when John was last seen on the server, You would type something like /seen John, but what if John decided to change his name to JohnDoe and you weren't aware of the change. The plugin would most likely throw an error saying that John never joined the server before. This would happen even if the plugin only stored John's UUID and not his recent name changes (which is what a lot of plugins are doing). Of course, memorising John's UUID is close to impossible (unless you wrote it down somewhere), so referring to players using their UUID is not an option.

For a long time now I've been wanting to contribute something to the Bukkit community since they really deserve it.  So, two days ago while in a Skype conversation, someone brought up UUIDs and I've really had enough of people suffering from the UUID change, even though everyone had 8+ months to come up with a solution. At that point in, I didn't get a chance to think of a solution, the idea just came to me.

So, I made a Bukkit plugin called PlayerNames. Simply put, PlayerNames keeps track of names that players logged on to the server with. If another player joins the server with a name that a player previously used, it changes the name owner to the new player.

The plugin supports two types of databases, YAML (Flatfile) and MySQL. I have plans for custom database implementation. It's extremely easy to use. You should only be concerned about one Java Class and that is PlayerNamesAPI. PlayerNamesAPI contains only static methods for easy access to the database.

The problem with this implementation is, if you type /seen John and John changes his name to JohnDoe, then Rick changes their name to John and joins the server, then it will think you are referring to Rick instead of John which can really be annoying.

As I said before, this idea came to me (which really makes me happy), so I didn't get a chance to rethink it. I'm sure there are better ways to go about this, but I really like my current implementation.

Enough chit-chat: Here's the source code. I can't be bothered to put up a jar download since I don't have Jenkins installed, but if I get bothered about it, I'll be sure to set something up.

Thank you for taking the time out of your day to read my post, please leave a comment below. :)

I'm always interested in writing applications in different languages. Personally, it helps me figure out which language is more interesting. Over the past couple of years, my time has been consumed by Java. Java is a great programming language, it's very powerful and there's a lot I've yet to learn from it. Although, a couple of days ago I was surfing the web very late at night and stumbled across this video. In the video, Ryan Dahl, the creator of Node.js, introduces Node.js and explains why its unique. The presentation had good humour so I kept watching, but when I saw that he could create a chat server with a few lines of code, I was astonished and immediately began reading more about the language.

The next day, I woke up and prepared to write my first Hello World application in JavaScript, which lucky enough for me, the syntax was similar to Java, therefore it was easy to understand. Hello World applications are never really that impressive, so I decided to challenge myself to write a chat server, one that not only looked neater, but provided the user more features. So here I am today, ready to show off my first Node.js application.

If you're lucky, you might be able to catch a live demo here.

When you first connect to the Chat server, you get a pop-up dialogue that lets you choose a nickname  to be identified by. This is not saved, so if you change your username or leave the chat, someone else can use it.

[caption id="" align="alignnone" width="1161"] Image of the pop-up dialogue prompting the connecting user to choose a nickname.[/caption]

[caption id="" align="alignnone" width="601"] Error displayed when the user attempts to choose a name that is already being used.[/caption]

After choosing your nickname, you can start chatting with other people in the chat, just like most chat application.

[caption id="" align="alignnone" width="1147"] Image displaying user connection messages. And the everyday fan boys.[/caption]

As you might notice, each message's header has the message sender and the time. The time is soon going to display the time since the last message rather than the time it was sent. There is a lot that can be done to improve this chat application and I intend to do my best to improve them. I definitely see myself creating more Node.js applications in the future, it is so easy yet very powerful.

One thing that sort of annoyed me was that every project has to contain its modules/dependencies, therefore making a project much larger.

Chat application source: on GitHub.

PS: Please feel free to criticize my work. I appreciate all feedback.