One database to serve them all, one schema to bind them all.

Oracle Databases are used for traditional enterprise applications and departmental systems in large enterprises. Debezium connector for Oracle is a great way to capture data changes from the transactional system of record and make them available for application use.

The second part of how to model, structure, and organize your Infrastructure-as-Code AWS CDK Project. Building from scratch until a CI/CD pipeline composition, all the cloud component resources, and services at AWS Cloud.

A sample of how to model, structure, and organize your Infrastructure-as-Code AWS CDK Project. Building from scratch until a CI/CD pipeline composition, all the cloud component resources, and services at AWS Cloud.

Cybersecurity platforms help achieve full visibility, security and control across every user on every device.

Follow this overview of how the concerns of Authentication and SSO come together to plug into Authorization (mainly in the scope of API authorization).

How to use this toolkit to test your upgrade process and how it helps you upgrade your TiDB with ease and happiness.

NAS is not a new technology but still plays a crucial role in providing capable data storage and accessibility through centralized storage connected to a network.

Date/time logic has many edge cases. Here, we'll look at strategies to bend the clock to your will for better testability.

This article was originally published on 1/5/14 The countdown for 2015 has already begun and so are the businesses eager to roll out new strategies and technical innovations with the New Year. Especially the entrepreneurs. 2014 has been a year of many ups and downs for most ventures due to the various algorithm updates rolled out by the search giant. Yet, overall 2014 has been a successful year for many companies that focused on adaptation to the technological shifts. 2015 too would be a year when many ventures would be a part of this transition – either to sustain or compete in the competitive market. Learning and recruiting people with new skills and implementing new tactics would be vital look-out next year. Considering the evolution in technology, virtualization, or rather cloud-based virtualization and remote management can be a key consideration for businesses that haven’t upgraded their IT to it yet. With the ever-increasing number of online stores and eCommerce sites, a strong emphasis would be given to scalable services – preferably automatic scaling. 2014 indeed saw growth in the adoption of cloud technology and mobile platform for business websites, moreover it’s also proved beneficial not just to buyers but also to retailers using eCommerce to run their operations. Talking about hosting, the term ‘cloud computing or cloud hosting’ was heard from almost every corner of the Industry. Due to the consistent advancements in the area of virtualization and remote operations, conventional organizations and new firms are increasingly opting for similar hosting solutions today. Let’s take a sneak peek at the two types of virtualization solutions that we have access to today. Cloud Hosting: Does it Make Sense? From a cost perspective, there is no doubt that cloud hosting is beginning to make a lot more sense for many website developers. They understand that they need to do something about getting their websites up, and the best way to make it happen is to use cloud hosting. It is so cost-effective because there are now plenty of services that offer cloud hosting to those who need it. You don’t really need to shop around for this service in the ways that you used to, and the costs have come down considerably as the infrastructure has improved. Thus, you may want to look into this as a possible way to spend some of your time and resources. Virtual Private Server (VPS) Hosting – VPS in simple terms is where a single physical server is divided into smaller virtual servers using virtualization technology. For that purpose, VMWare and HyperV (hardware hypervisors) are the two technologies that actually made a mark in 2014. Having a physical dedicated server virtualized using one of the hypervisors, allows the creation of multiple servers that inherit the properties of the base server - each acting as a dedicated server in itself (in a virtual environment). One of the major benefits of VPS hosting is, that dedicated resources can be assigned to the virtual machines. Much similar to that of a physical server. Pros – It offers flexibility along with complete control/root access to the server. VPS is typically less expensive as compared to cloud hosting. The user can modify the settings on the server to adjust it according to the requirements. Through a shared environment, VPS clients can take leverage of dedicated environments with specific resource allocations. With VPS hosting, dedicated IPs can be allocated to each account. Unless it is a hardware failure, any virtual server is affected and exposed to downtime, the other servers aren’t affected. As users get root access to the particular server, one can choose the operating system and install any required software which makes it quite easy to manage the VPS. Cons – If there is any problem with the VPS server and needs maintenance or rebooting or has a hard drive error then all accounts hosted on it would face downtime. Despite the inheritance of characteristics of a dedicated server, computing resources of the physical server are still distributed across VPS accounts. Hence, ill operations run by a neighboring account can pose an impact on your server. Though one can choose an operating system (OS) only one OS can run on each physical server. Storage space on each server is limited and so when your VPS reaches the maximum capacity, arrangements for additional space or migration to new hardware remain the only option. Which again means downtime. Cloud Server Hosting – Slightly an enhanced version of virtualization, a cloud server makes use of multiple servers which are connected together in a single network – known as a cluster which is backed by RAID configurations. Users would still have root access to the Virtual machine, but in this case, the resources are pulled from a massive pool and released back when unused. Pros – Cloud hosting offers greater flexibility as it is extended to multiple physical machines pooling in their resources into one. The storage space as well as the other resources can be scaled up/down as per requirements. If any physical server runs down or fails, the virtual machines or VMs have transported automatically to other servers within the same cluster. Hence avoiding the downtime resulting in the cloud hosting being more reliable. Since a VM uses resources from a massive pool, the question of running out of it is negligible. This helps ensure optimum performance – even during peak hours. Each client on the cloud has the privilege to choose the operating system individually. Though a load of other cloud customers increases, the computing resources – RAM, CPU performance, and bandwidth being pooled in by multiple physical servers, result in a near unlimited supply of resources. The cloud server is easier to suffice custom requirements. It means clients can choose the OS, firewall, control panels, and other applications. Cons – There’s only one disadvantage of cloud in comparison to a VPS, ie, it's a little more expensive. As a matter of fact, both the solutions have been popular in the year 2014 despite their individual benefits and demerits. Where VPSs were opted for by websites for whom scalability and up-time weren’t much of a concern, while on the other hand, the sites that did require them opted for cloud solutions. A few service providers even offered a pay-per-use billing model in Cloud, where users would only pay for the resources that their sites/applications have actually used. With further work being put into the development of the Cloud, and an increasing volume of applications depending more on the cloud, 2015 is expected to be more of a cloud-friendly year.

Performance is a big focus of the W3C Web Performance Working Group. Check out these APIs which provide a reference for web performance and W3C standards.

This is the second in a series of blog posts about real-world ReactJS usage and what we've learned scaling our app at Threat Stack.

Nowadays Quarkus is known as Supersonic Subatomic Java. It provides a lot of features to facilitate build and deployment.

This article was originally published on 3/19/15

The author conducts two tests with differing service delay times to measure any difference in performance between reactive and synchronous programming.

This deep dive of using Logback with Spring Boot includes how to use property files to alter the default Spring Boot settings and how to create custom configurations.

Learn more about discussing backend for front-end.

Build a Wordpress deployment as a cdk8s construct.

You have probably heard a lot of talk about the wonderful things the cloud can do for you, and you are probably curious about how those services may come into play in your daily life. If this sounds like you, then you need to know that cloud services are playing an increasingly important role in our lives, and we need to look at how they can change how we message one another. Many people are looking at Android cloud messaging as the next leap forward into a future where it is possible to reach out to the people we care about and save those messages directly in the cloud. Never miss the opportunity to communicate with someone who truly matters to you, and start using cloud storage to back up your messages. It is as simple as that! You might have heard of c2dm (cloud-to-device messaging), which basically allowed third-party applications to send (push) lightweight messages to their android applications. Well, c2dm as such is now deprecated and replaced with its successor up the evolutionary ladder: GCM, or google cloud messaging. GCM is a (free) service that allows developers to push two types of messages from their application servers to any number of android devices registered with the service: collapsible, "send-to-sync" messages non-collapsible messages with a payload up to 4k in size "Collapsible" means that the most recent message overwrites the previous one. A "send-to-sync" message is used to notify a mobile application to sync its data with the server. In case the device comes online after being offline for a while, the client will only get the most recent server message. If you want to add push notifications to your android applications, the getting started guide will walk you through the setup process step by step, even supplying you with a two-part demo application (client + server) that you can just install and play around with. The setup process will provide you with the two most essential pieces of information needed to run GCM: An API Key is needed by your server to send GCM push notifications A Sender ID is needed by your clients to receive GCM messages from the server Everything is summarized in the following screen you get after using the google API console: The quickest way to write both server and client code is to install the sample demo application and tweak it to your needs. In particular, you might want to at least do any of the following: Change the demo's in-memory datastore into a real persistent one. Change the type and/or the content of push messages. Change the client's automatic device registration on start-up to a user preference so that the handset user may have the option to register/unregister for the push notifications. We'll do the last option as an example. Picking up where the demo ends, here's a quick way to set up push preferences and integrate them into your existing android application clients. in your android project-resources ( res/xml) directory, create a preference.xml file such as this one: and the corresponding activity: // package here import android.os.bundle; import android.preference.preferenceactivity; public class pushprefsactivity extends preferenceactivity { @override protected void oncreate(bundle savedinstancestate) { super.oncreate(savedinstancestate); addpreferencesfromresource(r.xml.preferences); } } the above will provide the following ui: The "enable server push" checkbox is where your android application user decides to register for your push messages. Then, it's only a matter of using that preferences class in your main activity and doing the required input processing. the following skeleton class only shows your own code add-ons to the pre-existing sample application: // package here import com.google.android.gcm.gcmregistrar; // other imports here public class mainactivity extends activity { /** these two should be static imports from a utilities class*/ public static string server_url; public static string sender_id; private boolean push_enabled; /** called when the activity is first created. */ @override public void oncreate(bundle savedinstancestate) { super.oncreate(savedinstancestate); // other code here... processpush(); } /** check push on back button * if pushprefsactivity is next activity on stack */ @override public void onresume(){ super.onresume(); processpush(); } /** * enable user to register/unregister for push notifications * 1. register user if all fields in prefs are filled and flag is set * 2. un-register if flag is un-set and user is registered * */ private void processpush(){ if( checkpushprefs() && push_enabled ){ // register for gcm using the sample app code } if(! push_enabled && gcmregistrar.isregisteredonserver(this) ){ gcmregistrar.unregister(this); } } /** check server push preferences */ private boolean checkpushprefs(){ sharedpreferences prefs = preferencemanager .getdefaultsharedpreferences(this); string name = prefs.getstring("sname", ""); string ip = prefs.getstring("sip", ""); string port = prefs.getstring("sport", ""); string senderid = prefs.getstring("sid", ""); push_enabled = prefs.getboolean("enable", false); boolean allfilled = checkallfilled(name, ip, port, senderid); if( allfilled ){ sender_id = senderid; server_url = "http://" + ip + ":" + port + "/" + name; } return allfilled; } /** checks if any number of string fields are filled */ private boolean checkallfilled(string... fields){ for (string field:fields){ if(field == null || field.length() == 0){ return false; } } return true; } } The above is pretty much self-explanatory. Now GCM push notifications have been integrated into your existing application. If you are registered, you get a system notification message at each server push, even when your application is not running. Opening up the message will automatically open your application: GCM is pretty easy to set up since most of the plumbing work is done for you. a side note: if you like to isolate the push functionality in its own sub-package, be aware that the GCM service gcmintentservice, provided by the sample application and responsible for handling GCM messages, needs to be in your main package (as indicated in the-set up documentation)—otherwise GCM won't work. When communicating with the sample server via an HTTP post, the sample client does a number of automatic retries using exponential back-off, meaning that the waiting period before a retry in case of failure is each time twice the amount of the preceding wait period, up to the maximum number of retries (5 at the time of this writing). You might want to change that if it doesn't suit you. It may not matter that much, though, since those retries are done in a separate thread (using asynctask) from the main UI thread, which therefore minimizes the effects on your mobile application's pre-existing flow of operations.

Tight coupling between modules is a bad idea, and the worst form of coupling is cyclic dependencies between modules. Fortunately, there are a few techniques we can use to break the cycles. They are Callback, Escalation, and Demotion, and I’m going to walk through some examples that show each of them in action. Then, once the dependencies are broken, we’ll look at two more techniques that allow us to invert and eliminate the relationship altogether. The code for each of the samples can be found in the edcie project on my Google code repository. Each example includes a build script and a simple test case. To execute them though, you’ll need GraphViz if you want to use JarAnalyzer. To invoke the build scripts without invoking JarAnalyzer, you can simply type: ant compile Keep in mind that each variation of the system has the exact same behavior! Modules Can Teach Us Plenty There are a number of amazing lessons that we can all learn when we use modules to help mold our software products and help us create things that customers will truly want to check out. However, we should experiment carefully with the different modules that are available to us before settling on any particular one. It may be the case that we need to sample several of them before we ultimately decide that one or the other is a better use of our time. Think about this carefully, and make sure you tweak your modules as necessary to get the best possible results out of them. You may discover that there are more than a few out there that make the most sense for you in the long run. The Example The example we’re going to use to drive the remainder of our discussion is incredibly simple. We’ve got a Customer and a Bill class that we’re going to bundle into two separate modules - cust.jar and bill.jar. There’s also a test case called PaymentTest that serves as a sample client to drive the interactions between the two classes. The test case is bundled into the billtest.jar module. The initial class diagram is seen on the right. Note the bi-directional relationship between the two classes. As we progress, we’ll add more classes and abstractions to the system to help increase the modularity. Additionally, we’re going to use JarAnalyzer to illustrate the relationships between the modules and also help us assess the quality of our design. The module structure is below, as generated by JarAnalyzer. You can see how to use JarAnalyzer in the build by reviewing the build file. Again, our goal is to break the cyclic dependency between cust.jar and bill.jar, and we’re going to look at three different ways to do this before moving on to examine different ways to massage acyclic module relationships. Initial Module Structure with Cyclic Dependencies Escalation The first technique we’re going to apply is called Escalation. With Escalation, we break the cyclic dependencies by escalating the cause of the dependency to a higher-level entity. Before we do that, we need to more fully understand why a cyclic dependency exists in this example. This reason follows: A Customer has a list of Bill instances. When the payment method on Bill is invoked, the Bill needs to determine if a discount should be applied. The discount is a product of the Customer the bill belongs to, not necessarily the Bill. Therefore, the Bill class calls for a method for Customers to determine the appropriate discount amount. Think of it this way…The Customer represents a payee and we negotiate a discount with each payee. The calculation of this discounted amount is encapsulated within the Customer. To break this dependency, we want to escalate the cause of the dependency up to a higher level class - the CustomerMediator. The mediator now encapsulates the calculation of the discount and passes that to the bill class. The best way to see this change is to look at the modified PaymentTest class. Now, I’ve modified the build script and have bundled the mediator into its own module, as shown below. If you dig a bit more deeply into the class structure, you’ll wonder why I didn’t just pass the discount amount from the Customer into Bill. Don’t worry about that. This example is slightly contrived because escalation isn’t the best way to solve this type of problem. The key takeaway is that we’ve escalated the dependency up to the mediator.jar bundle, breaking the cyclic dependency. Escalating the Cause of the Cyclic Dependency Demotion A slightly better way to solve this particular type of cyclic dependency (where we have a true composite relationship between Customer and Bill) is to use demotion. With demotion, we push the cause of the dependency to a lower-level module. Exactly the opposite of escalation. We do this by introducing a DiscountCalculator class that will be passed into the Bill class. Our modified PaymentTest class will create the calculator and pass it in for us. The Customer class will serve as the factory for the DiscountCalculator, since it’s the Customer that knows the discount that must be applied. The new class structure can be seen on the right. Now we’ll modify our build script to create an additional calc.jar bundle which will contain the DiscountCalculator class. Our resulting module structure is shown below. Demoting the Cause of the Cyclic Dependency Already you can see how this is a more natural solution than escalation for this particular type of cyclic dependency problem. What’s the key difference you might ask? With escalation, notice how I would be able to deploy the cust.jar and bill.jar modules independently. While demotion is a more natural solution in this situation, it also means that to deploy bill.jar or cust.jar, I must also deploy calc.jar. The right solution is always going to be contextual and the ideal solution is likely to shift throughout the development lifecycle. Callback Using a Callback is similar to the Observer pattern. With this approach, we’ll refactor our DiscountCalculator class to an interface, and then modify the Customer class to implement this interface. This new class structure can be seen on the right. As it happens in this specific situation, using a Callback represents a combination of demotion and our initial solution. We’ll go back to passing the Customer into the Bill, but will pass it in as a DiscountCalculator type. Whereas in the Demotion example we bundled the DiscountCalculator in a separate module, we’ll now just include it in our bill.jar module. Note that putting the DiscountCalculator in the cust.jar module would introduce the cyclic dependency we’re trying to get rid of. The new module structure, which resembles our original version minus the cyclic dependency, is shown below. Using a Callback to Eliminate the Cyclic Dependency Inverting Relationships Now we’re going to play around a bit with the module relationships. While Callback seems like the most logical solution, what if we wanted to use the cust.jar module without the bill.jar module? Callback, as it’s implemented, doesn’t allow us to do this. But with a bit of trickery, I can actually invert the relationship between the cust.jar and bill.jar modules. I start by refactoring the Bill class to an interface. Then, to avoid split packages (where classes in the same package are bundled into separate modules), I move the Bill class into the same package as the Customer class. The new class diagram is shown on the right, and the inverted module structure is shown below. Inverted Module Structure Eliminating Relationships Inverting the relationships allows us to deploy the cust.jar module independent of the bill.jar module. Again, it’s all about need. But I’d like to explore another option based on another important need - the ability to test modules independently. Before inverting the relationships, I am able to test the bill.jar module independently. After inverting the relationships, I can test the cust.jar module independently. But what if I want to test (or deploy) both modules independently? To do this, I need to completely eliminate the relationship altogether. As it turns out, because I’ve got a pretty flexible class structure after I inverted the relationships (lots of abstract coupling), I can do this by simply bundling the two interfaces - Bill and DiscountCalculator - into a separate module. No other coding changes are required. I start by moving them to a new package called base. Then, I modify my build script to bundle these two interfaces into a separate base.jar module, and we successfully eliminated the relationship between the bill.jar and cust.jar modules, as shown below. Eliminating Relationships Between Modules Wrapping Up We’ve come a long way from our original version of the system. Two modules with a cyclic relationship to a module structure where the original modules don’t have any relationship to each other. This means these modules can be tested and deployed independently. If you follow this blog, you know I’ve written plenty about the tradeoffs between flexibility and complexity, use and reuse, and many other architectural and design challenges. I hope this little exercise has helped drive some of those concepts home. As a final note, to explore some of these design decisions a bit more deeply, and to examine the tradeoffs a bit more objectively, I encourage you to run the builds for each of the projects and examine the dependencies.html file in the stats directory. To do this, you’ll need to make sure JarAnalyzer is executed, which requires GraphViz. As you’ll see when comparing the initial version to the final version, we made considerable progress in improving the quality of the design.