Machine Learning (ML) research in the healthcare field has been ongoing for decades, but almost exclusively in the lab rather than in the doctor’s office. The problem of implementing ML in patient-facing settings largely stems from two barriers:
Artificial Intelligence (AI), and more pragmatically, Machine Learning (ML) have been called the new electricity that's powering the Fourth Industrial Revolution (4IR). AI is considered to be the ability for an artificial system to make cognitive decisions without human input, whereas ML is considered to be the ability for a computerized system to improve performance of an automated task over time. While AI is still futuristic, ML has been causing huge disruptions across multiple industries over the past decade. For example:
Technical debt is becoming an increasingly intractable problem for many organizations. Businesses that grew up fast because the only way to survive was to be first to market are now suffering the legacy of unbounded rapid development and workforce churn. There’s a raft of developers and operations folk out there tasked with maintaining a heap of spaghetti code they have little chance of understanding.
When getting started with machine learning (ML) you need data -- and lots of it. Data really forms the foundation of your machine learning strategy and we’ll look at some of the considerations around data in machine learning. In a previous post we built a dog identification microservice in Python. We’ll consider that same use case here when looking at how we need to work with our data.
ActiveState is excited to announce that the Tcl Dev Kit (TDK) is now open source! This critical piece of software enables Tcl developers to create standalone, deployable applications for Windows, MacOS, Linux, Solaris, AIX and HP-UX. The ongoing development of this project has been a joint effort between ActiveState and key members of the Tcl community for many years.
*Note: this post was originally posted on LinkedIn.
We’re starting our own March madness, and it’s all about machine learning (ML). Want to share your ML story? Drop me a Line!
ActiveState has been betting on Python for a while. We’ve been providing companies with Python language-builds since 1999. Since before it became the language of choice for data science projects. So we get why Python would be the means to bridge the worlds of data science and engineering.
In my previous post, Why baking security into products is important, I examined the reasons for pushing security leftwards in your development process. Assuming teams do this, how do you ensure security elements added earlier in the development process actually end up in production? Or more importantly, ensure that nothing is in production that shouldn’t be there. In other words, how do you prove your security and compliance process is achieving what it was intended to do.
I joined ActiveState last year. It’s the first time I’m working directly in the open source space. And along with learning a lot, it’s been remarkable to consider not only what the company has achieved but also the proliferation of open source software. I’ve been surprised to learn how many of us take open source for granted, especially since how it enables most of our day-to-day tech.
Can your build pipeline perfectly reproduce a build including its critical bug that is deployed to a particular subset of machines? Reproducible builds is a fundamental problem that any developer who’s shipped software has had to deal with at some point.