With Jamf, we offered a new form of employee communication with IT through the IT Self-Service application. In fact, it is a portal for company employees to change the status quo in established business processes within the company. Our position: IT Self-Service is an employee’s first IT companion and the first line of IT help. The main idea of this service is to create conditions to reduce the load on the IT-team and reduce the number of open tickets to HelpDesk. This means more efficient use of the company’s IT resources. ... Since classical DevOps engineers were at the origin of the company’s IT onboarding process automation, the scenario of computer preparation for onboarding was implemented with the world’s most popular DevOps configuration management system, Ansible. It’s written in Python using the declarative markup language YAML. The approach was respectable because it solved the problem of preparing computers for both macOS/Ubuntu platforms with a platform-dependent branching of the deployment script.
API discoverability is a key aspect of any API management initiative. The discoverability of an API directly impacts its adoption and usage. A typical big enterprise with multiple development teams might build hundreds of APIs that they would want to reuse internally or share with partners that build complementary applications. If the teams are not able to discover existing APIs, they might build a new API with the same functionality. It might lead to a duplication of efforts and underutilization of the existing API. It is also an unscalable practice to contact the API developer each time someone wants to use the API. There needs to be a better and more hands-off way for internal teams and partners to discover and understand the usage of these APIs without directly contacting the developers who built them. API discoverability does not just mean making it easy to find an API by providing an inventory. It should also address some key aspects that are important for an API consumer, such as understanding the API through documentation, request and response format, sign-up options, and the business terms and conditions (in case of a partner) of using the API.
Some of these [long-term fix] recommendations are hard. For instance, one way these systems get biased is they're obviously being run by for-profit organizations. The usual players are Google, Facebook and Amazon. They are banking on their algorithms trying to optimize user engagement, which on the surface seems like a good idea. The problem is, people don't engage with things just because they are good or relevant. More often, they engage with things because the content has certain kinds of emotions, like fear or hatred, or certain kinds of conspiracy. Unfortunately, this focus on engagement is problematic. It's primarily because an average user engages with things that are often not verified, but are entertaining. The algorithms essentially end up learning that, OK, that's a good thing to do. This creates a vicious cycle. A longer-term solution is to start breaking the cycle. That needs to happen from both sides. It needs to happen from these services, the tech companies that are targeting for higher engagement. They need to start changing their formula for how they consider engagement or how they optimize their algorithms for something other than engagement.
Having a good arsenal of questions at one’s disposal is a must for any leader, but the one staple of any leader is the open-ended question. Asking open-ended questions is like adjusting the lens of a camera, opening the aperture to create a wider field of view. This wider field sets a tone of receptivity, signaling that you are open to new information, in learning mode, and ready for a dialogue not a monologue. ... You may have heard the term active listening. It involves paying close attention to words and nonverbal actions and providing feedback to improve mutual understanding. But have you ever stopped to consider passive listening? Passive listening also involves listening closely to the speaker but without reacting. Instead, passive listening leaves space for silence. By combining both of these modes, we achieve what we call effective listening. ... One of the most powerful response techniques is the ability to ask questions. Questions frame the issue, remove ambiguity, expose gaps, reduce risk, give permission to engage, enable dialogue, uncover opportunities, and help to pressure-test logic.
The bug count measures what annoys our users the most - Bugs aren’t a measure of quality (that’s measured by things like fitness for purpose, reliable delivery, cost and other stuff). But bugs are what annoy our users most. If you don’t believe me, consider this: over 60% of users delete an app if it freezes, crashes or displays an error message. Cue P!nk. Bugs exist because we write them into our code: Complexity defeats good intentions - We all know where bugs come from: Developers writing code (enabled by users who want new functionality). Bugs are the visible evidence that our code is sufficiently complicated that we don’t fully understand it. We don’t like creating bugs and wish we didn’t do it and have developed some coping skills to address the problem … but we still write bugs into our code. Bugs (like tchotchkes) accumulate over time—every time we add or change functionality, to be precise - Everyone has an Aunt Edna where the inevitable result of her going out is that she brings home some new thing to put on a shelf. The inevitable result of creating software is more bugs (and, yes, more/better functionality).
Automation makes it possible to build a reliable continuous testing process that covers the functional and non-functional requirements of the software. Preferably this automation should be done from the beginning of product development to enable quick release and delivery of software and early feedback from the users. ... We see more and more organizations trying to adopt the DevOps mindset and way of working. Velinov stated that software engineers, including the QA engineers, have to care not only about how they develop, test, and deliver their software, but also about how they maintain and improve their live products. They have to think more and more about the end user. Velinov mentioned that a significant requirement is and has always been to deliver software solutions quickly to production, safely, and securely. That’s impacting the continuous testing, as the QAs have to adapt their processes to rely mainly on automation for quick and early feedback, he said.
Data science is an ever-changing field, thus keeping up with the latest trend and techniques is essential in ensuring consistent performance at work. For data scientists who keep a full-time job, it is unrealistic to spend weeks learning something new to be able to apply it to your working projects. We need to learn fast, and one way to achieve this is through learning by doing. Rather than getting lost in too many details and background information in a new concept, the fastest way to fully grasp it is to follow a trustworthy practical tutorial and replicate it, then try to make customized innovations to achieve better results in your projects. Take an example of learning the Random Forest algorithm. We sure need to know some basics about the algorithm — what it is, where it can be used, etc. Then we just use it in a current project, following some tutorials, and see what the results are. Blog posts with examples are great sources to educate yourself fast, compared to textbooks, or online courses. Lastly, we troubleshoot the results and look for ways to improve the application of the algorithm.
When it comes to security issues and fixes, it is extremely important to be able to differentiate between new and old findings because this will also eventually affect the next two pillars: prioritization and remediation. One of the things DevSecOps tools have made possible is a real-time understanding of what’s happening in our code, with processes aligned with developer workflows, such as fixes at commonly accepted gates, like pull requests, and even earlier with precommit hooks or in-IDE alerts. A similar approach to the way we prevent issues from being merged into our code base through common CI gating can be applied to runtime-related tools during the CD phase. In this way, you can prevent runtime-related issues from reaching production, as well. So if we are able to discover security flaws while we’re still coding or in predeployment to production systems, these can be handled now and within the developer or operational context and need never go into the backlog. This is a very important distinction between our categories of security issues.
Scaling too quickly increases a startup's burn rate, reducing the time it has to demonstrate key metrics for its next funding round and other milestone events, Yépez explains. Such a startup can also trash trusted customer relationships by failing to deliver goods or services as promised. “That burned cash won’t come back, and neither will that customer,” he cautions. Conversely, limited funding forces some struggling businesses to assign staff members tasks that fall outside of their skillsets. “These responsibilities often suffer from poor execution and may have severe consequences for the startup,” says Thomas Dolan, co-founder of 28Stone Consulting, an IT and fintech consulting firm. Many startups also neglect to protect their intellectual property. In their rush to go to market, some founders unwittingly disclose their core technology, or offer their core technology, to potential investors and other external parties. Such activity triggers deadlines for filing patent applications, says Kyle Graves, an attorney at law firm Snell & Wilmer.
“Cloud chaos” comes from a landscape of unknowns. What is our enterprise cloud architecture? How do public and private clouds co-exist? What about edge computing? How do we align legal and compliance requirements in the multi-cloud world for heavily regulated industries such as fintech? Those daunting tasks and risks reflect the multi-cloud complexity and chaos we constantly live in. Having worked with many organisations transitioning away from “cloud chaos”, I see similar challenges regardless of the size of the business. It takes a vast amount of effort to architect and manage multi-cloud platforms. Think about scalability, interoperability, consistency, and a unified user experience. Think about the skill sets and knowledge required to build and operate cloud-native apps. Also, think about automating and optimising cloud management, architect cloud, and edge infrastructure. Think about connecting and securing apps and clouds. And finally, think about app security, legal, and compliance among other areas. These challenges keep CIOs up at night.
Quote for the day:
"Be willing to make decisions. That's the most important quality in a good leader." -- General George S. Patton, Jr.