Day: March 29, 2023

Machine learning has become an integral part of many industries, from healthcare to finance and beyond. It provides us with the tools we need to derive meaningful insights and make better decisions. However, even the most accurate and well-trained machine learning models are useless if they're not deployed in a production environment. That's where machine learning model deployment comes in.

Deploying a machine learning model can be a daunting task, even for experienced engineers. There are many challenges to overcome, from choosing the right deployment platform to ensuring your model is optimized for production. But fear not; in this article, you'll learn advanced tips and techniques to help you optimize your machine learning model deployment process and avoid common pitfalls.

Software has become an essential part of our daily lives, from the apps on our phones to the programs we use at work. However, software, like all things, has a lifecycle, and as it approaches its end-of-life (EOL). 

Then it poses risks to the security, privacy, and performance of the system on which it runs.

In today's data-driven world, businesses across industries are increasingly dependent on data warehouse and data lake solutions to store, process, and analyze their ever-growing volumes of data. These traditional approaches have played a crucial role in helping organizations unlock the value hidden within their data, driving informed decision-making. However, as the data management landscape continues to evolve, businesses face new challenges related to data volume, variety, and velocity, coupled with the need for real-time insights, advanced analytics, and machine learning capabilities.

Overcoming Limitations: Data Lakehouses Emerge as the Next-Gen Data Management Solution

Traditional data warehouses excel at handling structured data and providing fast query performance, but often struggle with scalability and rigidity when incorporating new data sources or adapting to changing business needs. Data lakes, in contrast, offer flexible storage solutions for diverse data types but may lack the necessary performance, governance, and advanced analytics support modern organizations require.

Cloud-native technologies like Kubernetes enable companies to build software quickly and scale effortlessly. However, debugging these Kubernetes-based applications can be quite challenging due to the added complexity of building service-oriented architectures (microservices) and operating the underlying Kubernetes infrastructure. 

Bugs are inevitable and typically occur as a result of an error or oversight made during the software development process. So, in order for a business to keep pace with app delivery and keep their end users happy, developers need an efficient and effective way to debug. This involves finding, analyzing, and fixing these bugs. 

Providing a personal ReadMe to your new teammates and stakeholders as a Scrum Master is a great way to build trust and rapport while managing expectations at the same time. I do so regularly, and having a template for that purpose comes in handy.

Therefore, I thought it also might be an excellent exercise to test ChatGPT on more practical aspects of a Scrum Master’s work. So, please follow the complete path to having ChatGPT create a decent personal readme template for Scrum Masters — which took me less than 20 minutes.

In the following videos, I explain, using scenarios and examples, how to view the contents of a deployed message flow and how to retrieve and import resources that are deployed to an integration server in IBM App Connect Enterprise.

In the first video, I use a scenario where an HTTP request is sent to a message flow. The message flow sends a REST Request to a back-end REST API, and the REST API then returns a population estimate for a European city that was entered in the original request message that was sent to the message flow.

If you've ever implemented a Java project using a mainstream build system such as Ant, Maven, or Gradle, you've probably noticed that you need to use extra language to describe how to build your project.

While this may seem appealing for basic tasks, it can become trickier for more complicated ones. You need to learn a specific soup of XML, write verbose configurations, or write Kotlin DSLs that are intertwined with complex tooling. 

Previously we had a look at the lock class and how it works behind the scenes.
In this post, we shall look at LockSupport and its native methods which are one of the building blocks for locks and synchronization classes.

As we can see the methods of lock support are static and behind the scenes, they are based on the Unsafe class.
The Unsafe class is not intended to be used by your code directly thus only trusted code can obtain instances of it.

AI is the fastest-moving technology with a solution for every security concern for an enterprise. From building a privacy layer for data management systems to using natural language processing for detecting fraud in inbound messages such as emails, there's an abundance of whitespace to create. However, while communicating with several business leaders, I have found that most ignore the severity of what may seem like a minor problem: phishing scams through emails. 

Since emails are the primary mode of corporate communications, millions of employees worldwide risk attracting spam and exposing sensitive information. In fact, as per Proofpoint's findings, 83% of organizations were under email phishing attacks in 2022. 

I've heard a lot about Jira not being optimized for QA as, at its core, it is specifically a Project Management solution, and, therefore, it is not about test management. But let's be honest here, Jira feels unnecessarily complicated when you get started with it, regardless of your position or goals. And given it's the go-to standard for organizing and managing software development projects – of which QA is an integral part – you'll barely have a choice in the matter. 

That being said, Jira can (and should) be optimized in a way that is equally efficient for developing new features, testing, and releasing them. 

Many apps have some kind of user-specific information or data that is supposed to be accessed by a certain group of users and not by others. With these sorts of requirements comes a demand for fine-grained access handling. Whether for security or privacy reasons, dealing with sensitive data is an important topic for any app. Big or small, nobody wants to be on the wrong side of a data leakage scandal. So let’s dive in on what it means to handle sensitive or confidential information in our apps.

Regardless if you’re requesting access on Twitter, a bank, or your local library, identifying yourself is a crucial first step. Any sort of gateway needs a reliable way to verify if an access request is legitimate.

“Identity theft is not a joke.”
— Dwight Schrute

On the web, we encapsulate the process for identifying a user and granting them access as Auth, which stands for two related but distinct actions:

• Authentication: the act of confirming a user’s identity.
• Authorization: granting an authenticated user access to a resource.

It is possible to have authentication without authorization, but not the other way around. The strategy to implement authorization at a data management level can be loosely referred to as Row-Level Security (RLS), but RLS is actually a bit more than this. In this article, we will take a step deeper into managing sensitive user data and defining access roles to a user base.

A ‘row’, in this case, refers to an entry in a database table. For example, in a posts table, a row would be a single article, check this json representation:

{
    "posts": [
        {
            "id": "article_23495044",
            "title": "User Data Management",
            "content": "<huge blob of text>",
            "publishedAt": "2023-03-28",
            "author": "author_2929292"
        },
        // ...
    ]
}

To understand RLS, each object inside posts is a ‘row’.

The above data is enough for creating a filter algorithm to effectively enforce row-level security. Nonetheless, it’s crucial for scalability and data handling that such relationship is defined on your data layer. This way, any service that connects to your database will have all the required information to implement its own access-control logic as required. So for the above example, the schema for the posts table would roughly look like the following:

{
    "posts": {
        "columns": [
            {
                "name": "id",
                "type": "string"
            },
            // ... other primitive types
            // establish relationship with "authors"
            {
                "name": "author",
                "type": "link",
                "link": "authors"
            }
        ]
    }
}

In the above example, we define the type of each value in our posts database and establish a relationship to the authors table. So each post will receive the id of one author. This is a one-to-many relationship: one author can have many posts.

Of course, there are patterns to define many-to-many relationships as well. Take, for example, a team’s backlog. You may want only members of a certain team to have access. In such case, you can create a list of users with access to a specific resource (and thus being very granular about it), or you can define a table for team, and thus connecting a team to multiple tasks, and a team to multiple users: this pattern is called a junction table and is great for defining scoped access within your data layer.

Now we understand what authorization is and looks like in a few cases. This should be enough to design a mental model for defining access to our data. We understand that in order to use the granular access to our data effectively, our app must be aware of which user is using that particular instance of the app (aka who’s behind the mouse).

It is time to set up a reliable and cost-effective authentication. Cost-effective because it is counter-productive to re-authenticate the user on every request. And it increases the risk factor of attacks, so let’s keep auth requests to a minimum. The way our app stores the user credentials to re-use in a defined lifecycle is called a session.

There are multiple ways of authenticating users and handling sessions. I invite you to check Eric Burel’s article on “Authentication in Websites: A Banking Analogy”. It’s a great and thorough explanation of how authentication works.

From this moment on, let’s assume we did our due diligence: username and password are securely stored, an authentication provider is able to reliably verify our user’s identity and returns a session, which is an object carrying a userId matching our user’s row in the database.

So now that we have established what it means and the requirements each moving piece brings in order to get it working, our goal is the following:

1. Authentication
   The provider performs user authentication, the library creates a session, and the app receives that as a payload from the auth request.
2. Resource request
   Authenticated User performs request with resourceId; the app takes userId from session.
3. Granting access
   It filters all resources from the table to only the ones owned by userId and returns (if it exists) the one with resourceId.

With the above mental model defined, it is possible to any sort of implementation and properly design your queries. For example, on our first defined schema (posts and authors), we can use filters on our fetching service to only provide access to the results a user should have:

async function getPostsByAuthor(authorId: string) {
    return sdk.db.posts
        .filter({
            author: authorId
        })
        .getPaginated()
}

This contrived snippet is just to exemplify a bare-bones RLS implementation. Maybe as a food-for-thought so you can build upon it.

Hopefully, these concepts have offered extra clarity on defining access management to private and/or sensitive data. It’s important to note that there are security concerns before and around storing such kind of data which were beyond the scope of this article. As a general rule: store as little as you need and provide only the necessary amount of access to data. The least sensible data going over the wire or being stored by your app, the lesser the chance your app is a target or victim of attacks or leaks.

Let me know your questions or feedback in the comment section or on Twitter.

Software development plays a crucial role, leading many companies to outsource this function to third-party service providers. However, selecting the right software development partner can be daunting given the many factors that require consideration, with the partner's technical proficiency ranking high among them. This article delves deeper into assessing the technical expertise of a software development partner.

Relevant Experience

When you're on the hunt for a software development partner, one of the key factors to consider is their relevant experience. Finding a partner with experience in developing software applications that align with your project requirements is important. For instance, if you're looking to create a mobile application, it's wise to seek a partner with extensive experience in mobile app development.

Day two of Dynatrace Perform began with a great discussion between Kelsey Hightower, Distinguished Developer Advocate at Google Cloud Platform and Andi Grabner, DevOps Evangelist at Dynatrace. The theme of their discussion was redefining the boundaries of people, processes and platforms. 

Kelsey began the discussion by explaining that his career took off when he began focusing on the fundaments. When he sees something new, he takes a step back and thinks about the first time humans were involved in something like this.