Is Blitz.js the JavaScript Framework I’ve Been Waiting For?

The year was 2007. I was about to leave corporate America and try my first startup. I had been a Java architect for the past 10+ years and was ready to try something new. A friend of mine introduced me to a framework called “Ruby on Rails.” She said it was amazing how fast you could build stuff. Here is a link to the original “How to build a blog engine in 15 minutes with Ruby on Rails” video where David Heinemeier Hansson (DHH) shows us how to build a blog using Rails. After watching the video, I was sold that it was worth a try. I spent most of the next year building my startup primarily programming in Ruby on Rails. It took me a while to climb the fairly steep learning curve of Rails, and also to really learn the Ruby programming language, but once I did, I could build stuff faster than at any point in my 20+ year career. Rails has a doctrine of what makes it great; you can look at the nine items here. Looking back, what made Rails great for me personally was a handful of key things:

  • Convention over Configuration – Now most frameworks follow this paradigm, but Rails was the first to bring it to the masses. No more struggling with configuration files to get your environment set up properly, everything works right out of the box, and if you follow the rules, it’s painless.
  • DRY Coding – (Do NOT repeat yourself) – The idea here is that you only need to code something in one place to get it done. You don’t need to copy and paste code into five different places to get something to work. 
  • Developer Happiness & Productivity – Rails came with generators to get you started. They would create all the code you need to CRUD (Create, Read, Update, Delete) your resources. Rails also came with a handy console where you could test and debug your code in a full working environment. You could also code everything in one language, Rails provided helpers to generate most of the JavaScript you would need. Rails eliminated the multiple layers upon layers of coding you used to have to do to get something done.
  • True Reuse – We have been looking for the ability to reuse code for 20+ years. We have tried many different approaches, but Rails, because it is a complete ecosystem, has done the best job at it. When you are building an app, you can find a “gem” (which is a library) to do just about anything you want. For example, authentication, authorization, uploading files, paginating results – all these things come for free by using “gems” that are open source.
  • Majestic Monolith – For most of the applications we build, having a fully integrated, simple, coherent platform, and structure is the easiest way to build things. Sure, microservices and serverless have their place, but for 80% of the applications out there, having everything set up in one platform is the easiest way to construct software. Rails comes with all you need to build your User Interface, API, business logic and database.

Also worth noting is that Enterprise Java was the “state of the art” application architecture before Rails. The architecture of Enterprise Java looked something like this:

Company Internal Frameworks; Good, Bad, Boring

It is common for software companies to have their own internal frameworks. These frameworks sometimes contain the whole software development life cycle, and sometimes it just boils down to a few tools and utilities.

Consider Temenos TAFJ framework as a case study, this framework has written in Java and can be considered as one of the most complete frameworks in the world it contains all aspect of software development requirements, it has its own data access layer, business layer, etc. plus it provides a special programing language for its developers to develop a new product in such platform.

4 Mistakes That Prevent Your Java APIs From Having More Users

When you have more people using your Java APIs, your projects grow and naturally you become a better engineer. You become more likely to increase your incomes and join great new projects. It also enables people to get their jobs done faster. So it’s a win-win situation.

To keep those people who already use your API and attract more, you need to eliminate these 4 mistakes.

Architectural Approaches To Authorization in Server Applications: Activity-Based Access Control Framework

This article is about security. I’ll focus on this in the context of web applications, but I’ll also touch on other types of applications. Before I describe approaches and frameworks, I want to tell you a story.

Background

Throughout my years working in the IT sphere, I’ve had the opportunity to work on projects in a variety of fields. Even though the process of authenticating requirements remained relatively consistent, methods of implementing the authorization mechanism tended to be quite different from project to project. Authorization had to be written practically from scratch for the specific goals of each project; we had to develop an architectural solution, then modify it with changing requirements, test it, etc. All of this was considered a common process that developers could not avoid. Every time someone implemented a new architectural approach, we felt more and more that we should come up with a general approach that would cover the main authorization tasks and (most importantly) could be reused on other applications. This article takes a look at a generalized architectural approach to authorization based on an example of a developed framework.