This episode brings you an interview with Maria Colgan, Master Product Manager for Oracle Database. Maria joined Oracle in 1996, and since then has held positions as product manager for Oracle Database In-Memory and the Oracle Database query optimizer. Maria is the primary author of the SQLMaria blog and a contributing author to the Oracle Optimizer blog.
“With the Autonomous Database, data scientists and developers can basically help themselves, provision the database and get running and utilize it.” – Maria Colgan
Handling the host duties for this program is Alexa Weber Morales. An award-winning musician and writer, Alexa is director of developer content at Oracle. She is the former editor in chief of Software Development magazine, and has more than 15 years of experience as a technology content strategist and journalist.
In this program Maria talks about Oracle Autonomous Database and the new features that allow data scientists, developers, and others beyond traditional database users to help themselves.
This program is Groundbreakers Podcast #377. The interview was originally recorded on September 17, 2019 at Oracle Openworld. Listen!
On the Mic
- Podcast: Do Bloody Anything: The Changing Role of the DBA
- Podcast: Tech Predictions – 10 for 2020
- Podcast: Data is the New Oil – Artificial Intelligence and Oracle Digital Assistant
- Oracle Autonomous Database
The Oracle Groundbreakers Podcast is available via:
We just installed SEP Cloud and had all of our users install the client. Some of my windows users are software engineers using Visual Studio. The files we build are being quarantined everytime we build them. The get built in a different folder each time, so i can’t modify the policy to exclude the files as it needs the full path.
How do i set this up so our Visual Studio developers can work without having to un-quarantine the files everytime they build?
This post was originally published February 19, 2019 on AbleBlue.
In my former life as a consultant, I was constantly aware of the impact that the pace of cloud technology evolution has on IT professionals. Recently, while moderating a panel at Office and SharePoint Live! 360 in Orlando, I asked the question: “IT Pro vs. Developers, is it time to bury the hatchet?” The panel consisted of four great friends of mine, Eric Shupps and Ben Curry, representing the IT Pro side of the house; and Rob Windsor and Paul Schaeflein, representing the Developers.
As I watched, listened, cajoled and questioned, the general consensus from the developers was that IT still struggles with understanding “modern development and development tools.” While IT insists on Developers following a standard of practice, the IT pros themselves still use haphazard and sometimes risky procedures for themselves, and do not hold their IT teams to the higher standards development uses.
The general consensus from the attendees was they supported that contention. We heard story after story from the IT pros in the audience about how they are not supported with the right tools to become better, that the IT organizations are not investing in them and their future, that they are too busy fighting fires to take the time to learn something new.
While I do understand the reality that we are all busy, as a trainer in my previous life I recognize that organizations have to train their people and allow them the time to “Level Up” their skills. I think it is necessary for the employees’ well being, their organizations’ longevity, and ultimately the supportability of the systems they manage.
Microsoft makes it easier than ever for IT pros to get up and running with the necessary tooling to dip their toes in development waters, while making their job easier and providing a better process for the companies they support. IT pros may start by initially switching from PowerShell ISE to VSCode with the PowerShell Extension. If you are “just writing scripts,” step up and try writing PowerShell Modules instead.
Here are four ideas to get you started.
I am always thinking about how repetitive a task is. If I have to do it more than 2 times I’ll try to figure out how to be more efficient. For example, if you have ever written the same script over and over, start thinking about creating PowerShell Modules for the functions that you use repeatedly. These could be anything from routine maintenance tasks, to heroic data restoration tasks. By thinking about the tasks that would have to be executed in an emergency before the emergency happens, your stress level will be much lower when the day comes that you need the module.
Another idea to save time is using snippets when writing your code. There is a fantastic community project for Visual Studio Code (VSCode) called Awesome Snippets that will get you started. I have some customers that have created their own snippets that they share as a team.
On a recent project, I was concerned about the number of folks that were going to be messing with the module I was writing. I noticed a few individuals were not providing documentation, examples, or full sentences in the help text. Now this may not seem important, but if they are failing to properly document the code, how much attention are they paying to the code itself?
Back in November I had the pleasure to hear Thomas Vochten, MVP speak at SharePoint and Azure Connect in Haarlem, Netherlands. He demonstrated an approach to testing PowerShell using a module called Pester. This module ships with Windows 10 and there are updates available from the community. There are two reasons I really like this approach.
There is a “tax” associated with creating tests, however — it takes time that does not directly impact the delivery of your PowerShell code. I admit, I am not “writing the test first and then writing the code,” in true TDD fashion. In fact, the first module I used Pester to test was a module I thought was nearly complete. That is where the PesterHelpers module can bootstrap a bunch of tests for you by reading your existing module and generating tests for you.
I use version control for nearly everything I write. My documents are in OneDrive, not a version control system per se, but it is backed up to the cloud on every save. My blog posts are written in markdown, and version controlled in Azure DevOps (aka VisualStudio.com). All of my PowerShell modules and scripts are in separate projects by Customer and/or Project and stored in Azure DevOps. It doesn’t matter if it’s Azure DevOps or Github.com or any other system you are familiar with, most of these systems use a flavor of Git for version control. I think that every technical person should have a grasp of the basics of Git. You need to be able to Fork, Checkout, Branch, Add, Commit, and Merge with confidence.
I am pretty comfortable with this process because I use it every day. Do I NEED to? No, could I use OneDrive for my module files, sure. But by forcing myself to implement these practices, I can talk to a developer about Git and the issues they face with a shared understanding. I can transition from working on my Surface on the couch with my dog Ruby, to my home office, to the Mac at my downtown Austin office, with ease and confidence. It makes me comfortable knowing I have all the versions of my edits stored safely somewhere other than one hard drive. Further, as soon as you add a team, it becomes significantly easier to share your stuff.
Azure DevOps – Project Management, Version Control, Build Management, and Continuous Integration
I like to think of DevOps as thinking end to end, or holistically, in terms of the lifecycle of the work. From defining the problem to writing the first line of code to delivery to applying updates, “lifecycle” DevOps thinking will help your work be portable. For example, that cool module that you built that may, someday, need to be updated — are you the only person who has the code? Can your team update it confidently or update it without you? Can they change the code without erasing your farm, locking you out of the tenant, or causing other issues? Do they have to call you on your vacation…just in case?
DevOps is about supporting the enterprise and managing the lifecycle of your code whether you are a Developer an IT pro or a combination of the two. By creating testable code, you can configure your version control system to reject check-ins that do not pass the tests. You can configure the build server to automatically deploy your runbooks when they do pass the tests, so that they enter production as efficiently as possible.
In other words, I like to enjoy my vacations, and I assume you do, too
What items are on your shortlist for “The Next Thing” you want to learn to level up for your role?
|Update your feed preferences|
The MDX Toolkit supports:
- Android and iOS apps developed on the Xamarin platform
- Apps developed by using the PhoneGap (Apache Cordova) framework
These are the third-party frameworks tested and supported by Citrix to work with the MDX Toolkit.
Other third-party frameworks, such as Swift, are not guaranteed to work unless explicitly stated.