The term “high-functioning autism” has been criticized by many individuals within the autism community, as well as by advocates and experts, for a variety of reasons. While it is not inherently offensive to everyone, there are several concerns associated with its usage that highlight potential issues.
Continue readingThe task of finding an alternative name for what was formerly referred to as Asperger’s Syndrome is undoubtedly a complex and challenging endeavour. This challenge stems from the intricacies of capturing the essence of a unique cognitive profile within the broader autism spectrum while avoiding any unintended negative connotations or exclusionary subtext.
Continue readingWhile the historical association of Hans Asperger with the Nazi regime has cast a shadow over his name, it is worth considering the case for retaining the term “Asperger’s Syndrome” and allowing the past to become a part of history. By recognizing the valuable contributions made by Asperger’s and acknowledging the unique experiences of individuals previously diagnosed with Asperger’s Syndrome, we can strike a balance between honoring the legacy and promoting inclusivity.
Continue readingThe decision to move away from using the term “Asperger’s Syndrome” has raised concerns regarding the lack of meaningful consultation with the very community it represents. Furthermore, there are suggestions that this shift has been imposed upon the community by external forces, potentially fueled by underlying tensions within the broader Neurodiversity community. In the spirit of inclusivity and empowerment, it is essential to prioritize the voices and perspectives of autistic individuals when making decisions that directly impact their identities and well-being.
Continue readingAcross three decades of diving deep into the intricacies of IT, from software engineering to enterprise architecture, there’s a multitude of lessons I’ve unearthed. However, two recent experiences bring to light some invaluable insights about software delivery and the broader strokes of business ethos.
Consider a scenario where your project hinges on the delivery timeline of an external firm. A firm that’s been given two years to code a mere API HTTP PUT request, with the deadline stretching from mid to end September. The stakes? The very funding of your project. Enter the vendor’s sales representative: brimming with confidence, he assures an on-time delivery. Yet, when playfully challenged with a wager to affirm this confidence, he declines. A simple bet revealing the chasm between rhetoric and conviction.
Such instances resonate with an enduring truth in software delivery and business: actions always echo louder than words. The real “test” in business is not just about meeting estimates or deadlines, but about the conviction, commitment, and authenticity behind the promises.
However, alongside this test of commitment, lies another challenge I’ve grappled with regardless of the cap I wore: estimating software delivery. Despite my extensive track record, I’ve faced moments when estimates missed the mark. And I’m not alone in this.
Early in my career, Bill Vass, another IT leader, imparted a nugget of wisdom that remains etched in my memory. He quipped, “When it comes to developer estimates, always times them by four.” This wasn’t mere cynicism, but a recognition of the myriad unpredictabilities inherent in software development, reminiscent of the broader unpredictabilities in business.
Yet, the essence isn’t about perfecting estimates. It revolves around three pillars: honesty in setting and communicating expectations; realism in distinguishing optimism from capability; and engagement to ensure ongoing dialogue through the project’s ups and downs.
In the grand tapestry of IT and business, it’s not always the flawless execution of an estimate or a delivered promise that counts. At the end of the day, an estimate is just that; an estimate. The crux lies in how we navigate the journey, armed with authenticity, grounded expectations, and unwavering engagement. These cornerstones, combined with real-world lessons, are what construct the foundation of trust, catalyse collaborations, and steer us toward true success.
Below is a table that compares popular open-source licenses.
| License | Permissiveness | Copyleft | Patent Grant | Complexity | Attribution | Derivative & Redistribution Licensing | Examples |
|---|---|---|---|---|---|---|---|
| MIT License | Very high | None | No | Low | Required | Any license, No Requirement | jQuery, .NET Core |
| GNU GPL | Low | Strong | No | High | Required | GPL Only | Linux kernel, WordPress |
| GNU LGPL | Moderate | Weak | No | Moderate | Required | LGPL or More Permissive, Required LGPL | GTK |
| Apache License 2.0 | Very high | None | Yes | Moderate | Required with changes | Any license, No Requirement | Apache HTTPD, Kafka |
| BSD Licenses | Very high | None | No | Low | Varies by clause | Any license, No Requirement | FreeBSD, NetBSD |
| MPL 2.0 | Moderate | File-level | No | Moderate | Required | MPL or More Permissive, Required MPL | Firefox |
| Creative Commons | Varies | Varies | No | Low to Moderate | Varies by license type | Varies | Artwork, music, blogs |
| Eclipse Public License | Moderate | Moderate | No | Moderate | Required | Any license, No Requirement | Eclipse IDE |
Notes:
The difference between “license” and “licence” is primarily regional:
In essence, in American English, “license” serves as both the noun and verb form. In contrast, British English differentiates between the two: “licence” is the noun, and “license” is the verb. However, it’s crucial to remember the context and audience when writing, as using the appropriate form can enhance clarity and adherence to regional language standards.
Open source licenses allow developers to share their code with the public while also dictating how that code can be used, modified, and distributed. Different licenses cater to various philosophies and use cases. Here’s a comparison of some popular open source licenses:
Conclusion: Choosing a license depends on the developer’s goals. If they want maximum freedom and adaptability, MIT or BSD are excellent choices. If ensuring that derivative works remain open source is crucial, GPL might be the way to go. For something in between, MPL or LGPL could be ideal. As always, when considering licensing, it might be wise to consult with someone knowledgeable about intellectual property laws.
Amazon Rekognition Video offers real-time video analysis for streaming videos, and it’s tailored to handle video streams seamlessly. Using Rekognition Video, you can identify and recognize faces in real-time, detect unsafe content, and track people, among other features.
Here’s how Amazon Rekognition works with video streams:
Rekognition Video is integrated with Amazon Kinesis Video Streams, which captures, processes, and stores video streams for analytics and machine learning. Here’s a basic flow:
Track persons even when they are partially hidden from view in your video, such as when they go behind an object. This powerful feature offers:
Identify potentially unsafe or inappropriate content in your video streams. This feature’s capabilities include:
Here’s a high-level approach to setting up real-time video analysis:
In conclusion, Amazon Rekognition Video provides a powerful platform for real-time video analysis when paired with Kinesis Video Streams. It enables applications in security, monitoring, user engagement, content moderation, and more. Always refer to the official AWS documentation for the most up-to-date and detailed information.