Surveying web service technologies

For a future web service I'm planning to do for the side-project I'm working on, I'm considering the technology stacks available. It will be rather straight forward, to serve public information so it can be queried upon programmatically.

My default would be to use Spring Boot (Java) because that's what I'm most familiar with and can knock something out without much trouble. Other technologies I'm considering would be Django (Python), Express (Node) JS, Go (Golang), and .NET. I'm planning to read more about them in more detail at some point.

I came across company's blog that attempted to survey and review different web service technologies: http://optimalbi.com/blog/2016/09/28/whats-the-best-restful-web-api-framework-part-6/ 'great', I thought, but after reading in more detail they sort of just summarize and skip over things. For example, Spring (Java) was just skipped over because it seems that the authors just don't like Java for basically no real reason. They didn't review or consider Golang...again for no reason other than they couldn't be bothered. One comment from an author lead me to another blog post about Kotlin, of which they seem to be fond of: http://optimalbi.com/blog/2016/05/20/kotlin-dragging-java-into-the-modern-world/
The opening paragraph reaches too much, I think:

Java has a lot to offer for the modern cloud-driven world, but writing good, maintainable and human readable code has never been part of a Java developers life.

This is where Kotlin comes into things. Kotlin is a statically typed language that runs on the JVM (Java Virtual Machine) which is designed to write better and safer Java-like applications that also have a certain level of human readability.

I'm sorry, but to being able to write good, maintainable and human readable code is absolutely possible as a Java developer in their life. The same goes for a Kotlin developer, Python developer, etc. Kotlin being better, safer, more readable code than Java...well that's maybe true. Perhaps even likely. But that's difficult to quantify, because it's quite subjective. I'm pretty sure it's possible to write bad Kotlin code, like it's possible to write bad <insert language of choice> code. Bad code comes from bad developers/teams/culture. Good code comes from good developers/teams/culture. All modern programming languages, Java included, all have fantastic modern features or frameworks over the past to make the life of a developer easier and write great code.Yes, other modern languages may have new features before Java decides to adopt them, but that's a great benefit of Java - it's dependable, got the backing of a huge corporation, used throughout the world, etc. In my organization There's not enough room in any office to swing a cat without hitting someone who knows lots about Java. What about Kotlin? You must be joking.

So with this in mind, it makes perfect sense now why the end-result from their tech survey was "we love Express JS because we love Node JS". And that's perfectly fine. But there's no say benchmarking of performance from one language or framework to the next. Their result came down to how they felt about using the technology, experience, interest, etc, and Express ticked all their boxes. And that's perfectly fine. It's just that I came into reading the articles thinking it would be a certain way, and it was actually in a different light. I think my take-home message is to always keep an open mind when reading anything, especially online in a blog, because people will have different opinions, thoughts, and feelings, which may or may not have apparent basis, and that's OK.

Going back to the main topic, I think I'll make an initial implementation in Spring Boot and then move onto seeing how it could be done instead in Express. I'll keep an open mind.

NHS HackDay Manchester 2017 write-up

Last weekend I went to the NHS HackDay 'hackathon' in Manchester http://nhshackday.com/previous/events/2017/05/manchester/ In the end I couldn't stay for the 2nd day, so I can only comment on the one (Saturday).

The event was held in the Co-op 'Federation' building, on the top floor which looks to be like an incubator for internal 'agile' ideas, to get improvements off the ground and try new things out. Very much open-plan, plenty of space for people to break off into small groups and collaborate. Although I've been to hackathon events before, this was my first NHS Hackday, so I didn't really know what to expect apart from the general outlined schedule.

After the initial sign-in period, and introduction, people pitches their ideas to the group to get interest and help get potential projects off the ground. Then people were encouraged to find a project you're interested in, and get going. I picked the "NHS public data" project to join because that sounded very interesting to me, and something I could sink my teeth into. The pitch was to get openly available NHS stats data from CSV files into a more accessible format. There was quite an interest in this, with more than a dozen people interested from technical and non-technical backgrounds. So we split into 2 sub-groups, technical and non-technical to try to achieve something.

Of course I was part of the technical sub-group, and we started talking about the problem, and what we could potentially achieve over the weekend. These discussions the rest of the morning really, and from speaking with people from other teams they had a 'similar' problem with communication - conversations get dominated by one or two people. And I don't mean it's from the one person who pitched the idea, it's from others, who realize it or not, are simply constantly talking, and not letting others give their opinion. Then if your opinion is given, it's generally disregarded and considered as if you were interrupting. I think this is a big problem, and steps need to be taken to ensure everyone is included in a project. It should be the responsibility of everyone to ensure everyone else has an opportunity to give their thoughts and input. I realized this was happening, with many people just not speaking at all, so I would actively try to get people to speak up so everyone around would be included equally.

I also think another problem with communication is that since the event was NHS-related, clinicians can be whelming in their conversation, and are very poor in letting other speaks and seeking the opinion of others. For them, it seems whoever keeps talking or talks the loudest is the most important, and nobody else matters. This might fly in a hospital or clinical practice, is a very bad attitude to have, especially with new people who are volunteering, trying to understand, discuss, and work together for the 1st time in a new environment.

I'm going off-topic hear a little, but I feel strongly about correcting poor team communication. A team cannot perform well or produce good results who are unable to properly communicate effectively.

Regardless, for the project I get involved with, we managed to break down the technical tasks needed doing, and I encourages people to pick the area they want to work on so we might be able to show something by the end of it.

I picked the part of loading the data into a database, for which we chose MongoDB because it seemed to fit our needs (loose data schemas). Plus, we could get a freely hosted database through Mongo, one of the sponsors of the event. A normal SQL database would be fine, I'm sure, but since we essentially had a Mongo DBA on-call giving us cloud infrastructure for free, then why not? Otherwise I'd need to pay for my own hosting, for have a limited allowance, total number of queries, limited performance, etc.

I worked on loading some data into Mongo for the rest of the day, and I got somewhere, at least with local developmental testing. Our MongoDB was ready right at the end of the day, but regrettably I couldn't attend the 2nd day. I aim to work on this as a side-project in the coming weeks to properly explain this project, and see where I can get with it.

There was plenty of tea/coffee on-demand, but I forgot to bring power extender cables with me, so I know now for next time, if there is a next time, I should bring such niceties to make it even better. Well, I could even bring my own desktop and monitor with me next time if I want! Could be overkill, but there's nothing stopping me in all honesty.

All in all I had a lot of fun talking to new people, hearing about ideas about "how to make NHS IT less bad", and starting work on a side-project. For me, this is all very exciting and I really want to make progress into getting open NHS data more accessible. CSV or XLS files really aren't good enough, and maybe in the near future I'll be able to show something off.

I also have a couple ideas of my own that I might want to work on next as side-projects, or pitch them at future hack days.

The Feynman Technique

This blog post clearly explains the 'Feynman Technique' very well about how to learn new concepts better.

Essentially it consists of writing down the new concept in your own words as if you're explaining it to a new reader. Then if there are any gaps in your knowledge, or to check if what you've written is correct, refer to the source material and try again. And then repeat this process if there's anything complex that can be broken down further.

I think this is a very powerful technique because it "forces" you to properly understand material yourself first. In computing terms, it's absolutely apt - if you cannot break down something complex into something less complex so that others can understand, then you don't really understand the complexity yourself in the first place.

Marty Lobdell - Study Less Study Smart

Recently I came across this lecture by Marty Lobdell, called 'Study Less Study Smart'. I believe it's a fantastic overview about the pitfalls and fallacies about studying, and how, as a student learning new material, you can actively make a difference to study better.

From my perspective, it's easy to feel inundated with having to learn new technologies because there are so many options available, and new options are always being improved upon and evolving, or outright being invented. And then when learning an area, either completely new or in more detail regardless, it can feel like a chore instead of being 'fun', or there's a lack of productivity for gaining new knowledge and abilities.

This lecture, through many stories, anecdotes, and accepted results, explains how people can get the process of learning wrong, and how to get it right. It's an hour long, and well worth your time.