Base64 encoded strings are something that we as software developers encounter constantly in our day-to-day work. But, we usually pay little mind to how it operates and what it is actually doing for us.
In this post, we will help shed some light on Base64. We will discuss what it is, how it works, and why we choose to use it.
Both React and Angular are very popular front end development frameworks. In this post, I will discuss the similarities and differences between the two, and consider when one should be used instead of the other.
React is an open-source JavaScript library introduced by Facebook to build dynamic user interfaces. It is based on JavaScript and JSX (a PHP extension) and is considered widely for developing reusable HTML elements for front-end development.
Angular is an open-source front-end development framework powered by Google. It is a part of the MEAN stack and is compatible with a large number of code editors and is considered for creating dynamic websites and web apps.
In this post, we will begin by going over the benefits of React and Angular, then break down the differences between the two frameworks using thirteen attributes. By comparing each framework side by side, it can help decide which is the best framework for your specific app project.
This blog is about my dalliance with Elm; a purely functional, statically typed language that has type inference. It compiles to JavaScript. Functional programming is compelling, but heretofore, I’d only woven cherry-picked techniques into large object-oriented projects. In FP parlance, I’m partially applied! The times, they are a-changin’.
In this article, I’ll:
– touch on the reasoning for giving a nod to functional languages and data immutability;
– move on to Elm; a blazing-fast, statically typed, purely functional browser-side language that compiles to JavaScript and follows the principles of functional reactive programming;
– survey background items and the Elm environment;
– show a simple type-and-click application, followed by a more realistic To-do application;
– end with my impressions from functional-programming semi-outsider point-of-view.
When you think of common programming techniques and processes, what comes to mind first? Perhaps it’s test-driven development, writing an automated test to start your development cycle and putting testing at the forefront instead of the typical afterthought. Or maybe you thought of behavior driven development with stakeholders collaborating and defining the software behavior upfront thus mitigating the ambiguities from some requirements. But what if I told you that while testing and behavior are important, accessibility should be one of the first development considerations?
Maybe the whole concept of accessibility is nothing new to you, and you’re already accounting for it in all aspects of the development process. But, if you’re like most developers (myself occasionally included), accessibility along with unit testing are the two things you often save to the very, very, very end, or perhaps you save them for the newbies to worry about in a future sprint – neither of which is ideal. While it may not be quite as important in some industries as it is in others like government (where Section 508 is federal law regarding accessibility), addressing it should be in the forefront of your thought process, your code, and your testing.
I’ve been in the software development business for a long time and I can’t tell you how many login screens with authentication logic I have implemented. You might say that one of the most prevalent user stories is the need to log in and securely authenticate a user’s access to an application.
Here at Keyhole Software, we have implemented countless login and authentication approaches for applications, along with simple to sophisticated authorization schemes enforcing access control of applications. Of course, you can utilize the single sign-on type of technologies such as OAuth or OpenID, which offload the development of a login UI and the logic for authentication/authorization. However, these standards are not always utilized in enterprise environments. Many enterprises will have a single authentication mechanism that exploits a federated operating system network such as LDAP. A login UI still has to be created and authorization rules still have to be applied to each application.
Over the last few years, we have helped organizations transition away from monolithic-based applications to isolated microservice-based architectures. With Microservices, authentication and authorization logic is now spread across many decoupled distributed processes. It was a bit simpler with monolithic architectures as only a single process is authenticated and contains access control rules defined.
In this blog, we discuss a design pattern for authorization and authentication for use in a distributed microservices environment.