AI Analyst Jobs

AI Analyst Jobs — independent reviews, comparisons, pricing and step-by-step guides on Aizhi.

CMU Pronouncing Dictionary

The CMU Pronouncing Dictionary (also known as CMUdict) is an open-source pronouncing dictionary originally created by the Speech Group at Carnegie Mellon University (CMU) for use in speech recognition research. CMUdict provides a mapping orthographic/phonetic for English words in their North American pronunciations. It is commonly used to generate representations for speech recognition (ASR), e.g. the CMU Sphinx system, and speech synthesis (TTS), e.g. the Festival system. CMUdict can be used as a training corpus for building statistical grapheme-to-phoneme (g2p) models that will generate pronunciations for words not yet included in the dictionary. The most recent release is 0.7b; it contains over 134,000 entries. An interactive lookup version is available. == Database format == The database is distributed as a plain text file with one entry to a line in the format "WORD " with a two-space separator between the parts. If multiple pronunciations are available for a word, variants are identified using numbered versions (e.g. WORD(1)). The pronunciation is encoded using a modified form of the ARPABET system, with the addition of stress marks on vowels of levels 0, 1, and 2. A line-initial ;;; token indicates a comment. A derived format, directly suitable for speech recognition engines is also available as part of the distribution; this format collapses stress distinctions (typically not used in ASR). The following is a table of phonemes used by CMU Pronouncing Dictionary. == History == == Applications == The Unifon converter is based on the CMU Pronouncing Dictionary. The Natural Language Toolkit contains an interface to the CMU Pronouncing Dictionary. The Carnegie Mellon Logios tool incorporates the CMU Pronouncing Dictionary. PronunDict, a pronunciation dictionary of American English, uses the CMU Pronouncing Dictionary as its data source. Pronunciation is transcribed in IPA symbols. This dictionary also supports searching by pronunciation. Some singing voice synthesizer software like CeVIO Creative Studio and Synthesizer V uses modified version of CMU Pronouncing Dictionary for synthesizing English singing voices. Transcriber, a tool for the full text phonetic transcription, uses the CMU Pronouncing Dictionary 15.ai, a real-time text-to-speech tool using artificial intelligence, uses the CMU Pronouncing Dictionary
Read more →
Software requirements

Software requirements for a system are the description of what the system should do, the service or services that it provides and the constraints on its operation. The IEEE Standard Glossary of Software Engineering Terminology defines a requirement as: A condition or capability needed by a user to solve a problem or achieve an objective A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document A documented representation of a condition or capability as in 1 or 2 The activities related to working with software requirements can broadly be broken down into elicitation, analysis, specification, and management. Note that the wording Software requirements is additionally used in software release notes to explain, which depending on software packages are required for a certain software to be built/installed/used. == Elicitation == Elicitation is the gathering and discovery of requirements from stakeholders and other sources. A variety of techniques can be used such as joint application design (JAD) sessions, interviews, document analysis, focus groups, etc. Elicitation is the first step of requirements development. == Analysis == Analysis is the logical breakdown that proceeds from elicitation. Analysis involves reaching a richer and more precise understanding of each requirement and representing sets of requirements in multiple, complementary ways. Requirements Triage or prioritization of requirements is another activity which often follows analysis. This relates to Agile software development in the planning phase, e.g. by Planning poker, however it might not be the same depending on the context and nature of the project and requirements or product/service that is being built. == Specification == Specification involves representing and storing the collected requirements knowledge in a persistent and well-organized fashion that facilitates effective communication and change management. Use cases, user stories, functional requirements, and visual analysis models are popular choices for requirements specification. == Validation == Validation involves techniques to confirm that the correct set of requirements has been specified to build a solution that satisfies the project's business objectives, and to detect and correct errors in the requirements before implementation. == Management == Requirements change during projects and there are often many of them. Management of this change becomes paramount to ensuring that the correct software is built for the stakeholders. == Tool support for Requirements Engineering == === Tools for Requirements Elicitation, Analysis and Validation === Taking into account that these activities may involve some artifacts such as observation reports (user observation), questionnaires (interviews, surveys and polls), use cases, user stories; activities such as requirement workshops (charrettes), brainstorming, mind mapping, role-playing; and even, prototyping; software products providing some or all of these capabilities can be used to help achieve these tasks. There is at least one author who advocates, explicitly, for mind mapping tools such as FreeMind; and, alternatively, for the use of specification by example tools such as Concordion. Additionally, the ideas and statements resulting from these activities may be gathered and organized with wikis and other collaboration tools such as Trello. The features actually implemented and standards compliance vary from product to product. === Tools for Requirements Specification === A Software requirements specification (SRS) document might be created using general-purpose software like a word processor or one of several specialized tools. Some of these tools can import, edit, export and publish SRS documents. It may help to make SRS documents while following a standardised structure and methodology, such as ISO/IEC/IEEE 29148:2018. Likewise, software may or not use some standard to import or export requirements (such as ReqIF) or not allow these exchanges at all. === Tools for Requirements Document Verification === Tools of this kind verify if there are any errors in a requirements document according to some expected structure or standard. === Tools for Requirements Comparison === Tools of this kind compare two requirement sets according to some expected document structure and standard. === Tools for Requirements Merge and Update === Tools of this kind allow the merging and update of requirement documents. === Tools for Requirements Traceability === Tools of this kind allow tracing requirements to other artifacts such as models and source code (forward traceability) or, to previous ones such as business rules and constraints (backwards traceability). === Tools for Model-Based Software or Systems Requirement Engineering === Model-based systems engineering (MBSE) is the formalised application of modelling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later lifecycle phases. It is also possible to take a model-based approach for some stages of the requirements engineering and, a more traditional one, for others. Very many combinations might be possible. The level of formality and complexity depends on the underlying methodology involved (for instance, i is much more formal than SysML and, even more formal than UML) === Tools for general Requirements Engineering === Tools in this category may provide some mix of the capabilities mentioned previously and others such as requirement configuration management and collaboration. The features actually implemented and standards compliance vary from product to product. There are even more capable or general tools that support other stages and activities. They are classified as ALM tools.
Read more →
Directional cubic convolution interpolation

Directional cubic convolution interpolation (DCCI) is an edge-directed image scaling algorithm created by Dengwen Zhou and Xiaoliu Shen. By taking into account the edges in an image, this scaling algorithm reduces artifacts common to other image scaling algorithms. For example, staircase artifacts on diagonal lines and curves are eliminated. The algorithm resizes an image to 2x its original dimensions, minus 1.
Read more →
GeneXus

GeneXus is a low code, cross-platform, knowledge representation-based development tool, mainly oriented towards enterprise-class applications for web applications, smart devices, and the Microsoft Windows platform. GeneXus uses mostly declarative language to generate native code for multiple environments. It includes a normalization module, which creates and maintains an optimal database structure based on user views. The languages for which code can be generated include COBOL, Java, Objective-C, RPG, Ruby, Visual Basic, and Visual FoxPro. Some of the DBMSs supported are Microsoft SQL Server, Oracle, IBM Db2, Informix, PostgreSQL, and MySQL. GeneXus was developed by Uruguayan company ARTech Consultores SRL which later renamed to Genexus SA. The latest version is GeneXus 18, which was released on November 10, 2022.
Read more →
Plum Voice

The Plum Group, Inc. (DBA Plum Voice) is a company. Plum is headquartered in New York City with offices in Boston and Denver. == History == Plum Voice, founded in 2000 as The Plum Group, Inc., was incorporated to create technologies for personalized audio communication. By 2001, Plum had commercialized the open-standard Plum VoiceXML IVR platform which facilitated the creation of dynamic telecom applications. 2001 - Commercial launch of Plum VoiceXML IVR platform for customer-premises deployment 2002 - Launch of Plum Voice Hosting Centers for 24x7x365 managed IVR hosting 2004 - Plum Voice application suite receives a "Product of the Year" award from Customer Interactions magazine 2008 - Plum Survey builder launched, a do-it-yourself IVR survey tool. 2010 - Plum launched QuickFuse, a web-based rapid development platform used to create voice applications. 2013 - Plum launched VoiceTrends, an analytics and reporting toolkit designed specifically for voice applications. Plum achieves PCI-DSS Level 1. 2015 - Plum launched Plum Insight, a multi-channel (voice, web, mobile) survey platform. Plum achieves HIPAA compliance. 2016 - Plum launched a new version of QuickFuse called Fuse+. 2020 - Plum sunsets QuickFuse, rebrands Fuse+ as Plum Fuse.
Read more →
Unit of work

A unit of work is a behavioral pattern in software development. Martin Fowler has defined it as everything one does during a business transaction which can affect the database. When the unit of work is finished, it will provide everything that needs to be done to change the database as a result of the work. A unit of work encapsulates one or more code repositories[de] and a list of actions to be performed which are necessary for the successful implementation of self-contained and consistent data change. A unit of work is also responsible for handling concurrency issues, and can be used for transactions and stability patterns.[de]
Read more →
GNU toolchain

The GNU toolchain is a broad collection of programming tools produced by the GNU Project. These tools form a toolchain (a suite of tools used in a serial manner) used for developing software applications and operating systems. The GNU toolchain plays a vital role in development of Linux, some BSD systems, and software for embedded systems. Parts of the GNU toolchain are also directly used with or ported to other platforms such as Solaris, macOS, Microsoft Windows (via Cygwin and MinGW/MSYS/WSL2), Sony PlayStation Portable (used by PSP modding scene) and Sony PlayStation 3. == Components == Projects in the GNU toolchain are: GNU Autotools (build system) – Software build toolset from GNU GNU Binutils – GNU software development tools for executable code GNU Bison – Yacc-compatible parser generator program GNU C Library – GNU implementation of the standard C libraryPages displaying short descriptions of redirect targets GNU Compiler Collection – Free and open-source compiler for various programming languages GNU Debugger – Source-level debugger GNU m4 – General-purpose macro processor GNU make – Software build automation tool
Read more →
Software construction

Software construction is the process of creating working software via coding and integration. The process includes unit and integration testing although does not include higher level testing such as system testing. Construction is an aspect of the software development lifecycle and is integrated in the various software development process models with varying focus on construction as an activity separate from other activities. In the waterfall model, a software development effort consists of sequential phases including requirements analysis, design, and planning which are prerequisites for starting construction. In an iterative model such as scrum, evolutionary prototyping, or extreme programming, construction as an activity that occurs concurrently or overlapping other activities. Construction planning may include defining the order in which components are created and integrated, the software quality management processes, and the allocation of tasks to teams and developers. To facilitate project management, numerous construction aspects can be measured; these include the amount of code developed, modified, reused, and destroyed, code complexity, code inspection statistics, faults-fixed and faults-found rates, and effort expended. These measurements can be useful for aspects such as ensuring quality and improving the process. == Activities == Construction includes many activities. === Coding === The following are a few of the key aspects of the coding activity: Naming Choice of name for each identifier. One study showed that the effort required to debug a program is minimized when variable names are between 10 and 16 characters. Logic Organization into statements and routines Highly cohesive routines proved to be less error prone than routines with lower cohesion. A study of 450 routines found that 50 percent of the highly cohesive routines were fault free compared to only 18 percent of routines with low cohesion. Another study of a different 450 routines found that routines with the highest coupling-to-cohesion ratios had 7 times as many errors as those with the lowest coupling-to-cohesion ratios and were 20 times as costly to fix. Although studies showed inconclusive results regarding the correlation between routine sizes and the rate of errors in them, but one study found that routines with fewer than 143 lines of code were 2.4 times less expensive to fix than larger routines. Another study showed that the code needed to be changed least when routines averaged 100 to 150 lines of code. Another study found that structural complexity and amount of data in a routine were correlated with errors regardless of its size. Interfaces between routines are some of the most error-prone areas of a program. One study showed that 39 percent of all errors were errors in communication between routines. Unused parameters are correlated with an increased error rate. In one study, only 17 to 29 percent of routines with more than one unreferenced variable had no errors, compared to 46 percent in routines with no unused variables. The number of parameters of a routine should be 7 at maximum as research has found that people generally cannot keep track of more than about seven chunks of information at once. One experiment showed that designs which access arrays sequentially, rather than randomly, result in fewer variables and fewer variable references. One experiment found that loops-with-exit are more comprehensible than other kinds of loops. Regarding the level of nesting in loops and conditionals, studies have shown that programmers have difficulty comprehending more than three levels of nesting. Control flow complexity has been shown to correlate with low reliability and frequent errors. Modularity Structuring and refactoring the code into classes, packages and other structures. When considering containment, the maximum number of data members in a class shouldn't exceed 7±2. Research has shown that this number is the number of discrete items a person can remember while performing other tasks. When considering inheritance, the number of levels in the inheritance tree should be limited. Deep inheritance trees have been found to be significantly associated with increased fault rates. When considering the number of routines in a class, it should be kept as small as possible. A study on C++ programs has found an association between the number of routines and the number of faults. A study by NASA showed that the putting the code into well-factored classes can double the code reusability compared to the code developed using functional design. Error handling Encoding logic to handle both planned and unplanned errors and exceptions. Resource management Managing computational resource use via exclusion mechanisms and discipline in accessing serially reusable resources, including threads or database locks. Security Prevention of code-level security breaches such as buffer overrun and array index overflow. Optimization Optimization while avoiding premature optimization. Documentation Both embedded in the code as comments and as external documents. === Integration === Integration is about combining separately constructed parts. Concerns include planning the sequence in which components will be integrated, creating scaffolding to support interim versions of the software, determining the degree of testing and quality work performed on components before they are integrated, and determining points in the project at which interim versions are tested. === Testing === Testing can reduce the time between when faulty logic is inserted in the code and when it is detected. In some cases, testing is performed after code has been written, but in test-first programming, test cases are created before code is written. Construction includes at least two forms of testing, often performed by the developer who wrote the code: unit testing and integration testing. === Reuse === Software reuse entails more than creating and using libraries. It requires formalizing the practice of reuse by integrating reuse processes and activities into the software life cycle. The tasks related to reuse in software construction during coding and testing may include: selection of the reusable code, evaluation of code or test re-usability, reporting reuse metrics. === Quality assurance === Techniques for ensuring quality as software is constructed include: Testing One study found that the average defect detection rates of Unit testing and integration testing are 30% and 35% respectively. Software inspection With respect to software inspection, one study found that the average defect detection rate of formal code inspections is 60%. Regarding the cost of finding defects, a study found that code reading detected 80% more faults per hour than testing. Another study shown that it costs six times more to detect design defects by using testing than by using inspections. A study by IBM showed that only 3.5 hours were needed to find a defect through code inspections versus 15–25 hours through testing. Microsoft has found that it takes 3 hours to find and fix a defect by using code inspections and 12 hours to find and fix a defect by using testing. In a 700 thousand lines program, it was reported that code reviews were several times as cost-effective as testing. Studies found that inspections result in 20% - 30% fewer defects per 1000 lines of code than less formal review practices and that they increase productivity by about 20%. Formal inspections will usually take 10% - 15% of the project budget and will reduce overall project cost. Researchers found that having more than 2 - 3 reviewers on a formal inspection doesn't increase the number of defects found, although the results seem to vary depending on the kind of material being inspected. Technical review With respect to technical review, one study found that the average defect detection rates of informal code reviews and desk checking are 25% and 40% respectively. Walkthroughs were found to have a defect detection rate of 20% - 40%, but were found also to be expensive especially when project pressures increase. Code reading was found by NASA to detect 3.3 defects per hour of effort versus 1.8 defects per hour for testing. It also finds 20% - 60% more errors over the life of the project than different kinds of testing. A study of 13 reviews about review meetings, found that 90% of the defects were found in preparation for the review meeting while only around 10% were found during the meeting. Static analysis With respect to Static analysis (IEEE1028), studies have shown that a combination of these techniques needs to be used to achieve a high defect detection rate. Other studies showed that different people tend to find different defects. One study found that the extreme programming practices of pair programming, desk checking, unit testing, integration testing, and regression testing can achieve a 90% defect detection rate. An experiment involving exper
Read more →
Site reliability engineering

Site reliability engineering (SRE) is a discipline in the field of software engineering and IT infrastructure support that monitors and improves the availability and performance of deployed software systems and large software services (which are expected to deliver reliable response times across events such as new software deployments, hardware failures, and cybersecurity attacks). There is typically a focus on automation and an infrastructure as code methodology. SRE uses elements of software engineering, IT infrastructure, web development, and operations to assist with reliability. It is similar to DevOps as they both aim to improve the reliability and availability of deployed software systems. == History == Site Reliability Engineering originated at Google with Benjamin Treynor Sloss, who founded SRE team in 2003. The concept expanded within the software development industry, leading various companies to employ site reliability engineers. By March 2016, Google had more than 1,000 site reliability engineers on staff. Dedicated SRE teams are common at larger web development companies. In middle-sized and smaller companies, DevOps teams sometimes perform SRE, as well. Organizations that have adopted the concept include Airbnb, Dropbox, IBM, LinkedIn, Netflix, and Wikimedia. == Definition == Site reliability engineers (SREs) are responsible for a combination of system availability, latency, performance, efficiency, change management, monitoring, emergency response, and capacity planning. SREs often have backgrounds in software engineering, systems engineering, and/or system administration. The focuses of SRE include automation, system design, and improvements to system resilience. SRE is considered a specific implementation of DevOps; focusing specifically on building reliable systems, whereas DevOps covers a broader scope of operations. Despite having different focuses, some companies have rebranded their operations teams to SRE teams. == Principles and practices == Common definitions of the practices include (but are not limited to): Automation of repetitive tasks for cost-effectiveness. Defining reliability goals to prevent endless effort. Design of systems with a goal to reduce risks to availability, latency, and efficiency. Observability, the ability to ask arbitrary questions about a system without having to know ahead of time what to ask. Common definitions of the principles include (but are not limited to): Toil management, the implementation of the first principle outlined above. Defining and measuring reliability goals—SLIs, SLOs, and error budgets. Non-Abstract Large Scale Systems Design (NALSD) with a focus on reliability. Designing for and implementing observability. Defining, testing, and running an incident management process. Capacity planning. Change and release management, including CI/CD. Chaos engineering. == Deployment == SRE teams collaborate with other departments within organizations to guide the implementation of the mentioned principles. Below is an overview of common practices: === Kitchen Sink === Kitchen Sink refers to the expansive and often unbounded scope of services and workflows that SRE teams oversee. Unlike traditional roles with clearly defined boundaries, SREs are tasked with various responsibilities, including system performance optimization, incident management, and automation. This approach allows SREs to address multiple challenges, ensuring that systems run efficiently and evolve in response to changing demands and complexities. === Infrastructure === Infrastructure SRE teams focus on maintaining and improving the reliability of systems that support other teams' workflows. While they sometimes collaborate with platform engineering teams, their primary responsibility is ensuring up-time, performance, and efficiency. Platform teams, on the other hand, primarily develop the software and systems used across the organization. While reliability is a goal for both, platform teams prioritize creating and maintaining the tools and services used by internal stakeholders, whereas Infrastructure SRE teams are tasked with ensuring those systems run smoothly and meet reliability standards. === Tools === SRE teams utilize a variety of tools with the aim of measuring, maintaining, and enhancing system reliability. These tools play a role in monitoring performance, identifying issues, and facilitating proactive maintenance. For instance, Nagios Core is commonly employed for system monitoring and alerting, while Prometheus (software) is frequently used for collecting and querying metrics in cloud-native environments. === Product or Application === SRE teams dedicated to specific products or applications are common in large organizations. These teams are responsible for ensuring the reliability, scalability, and performance of key services. In larger companies, it's typical to have multiple SRE teams, each focusing on different products or applications, ensuring that each area receives specialized attention to meet performance and availability targets. === Embedded === In an embedded model, individual SREs or small SRE pairs are integrated within software engineering teams. These SREs collaborate with developers, applying core SRE principles—such as automation, monitoring, and incident response—directly to the software development lifecycle. This approach aims to enhance reliability, performance, and collaboration between SREs and developers. === Consulting === Consulting SRE teams specialize in advising organizations on the implementation of SRE principles and practices. Typically composed of seasoned SREs with a history across various implementations, these teams provide insights and guidance for specific organizational needs. When working directly with clients, these SREs are often referred to as 'Customer Reliability Engineers.' In large organizations that have adopted SRE, a hybrid model is common. This model includes various implementations, such as multiple Product/Application SRE teams dedicated to addressing the specific reliability needs of different products. An Infrastructure SRE team may collaborate with a Platform engineering group to achieve shared reliability goals for a unified platform that supports all products and applications. == Industry == Since 2014, the USENIX organization has hosted the annual SREcon conference, bringing together site reliability engineers from various industries. This conference is a platform for professionals to share knowledge, explore effective practices, and discuss trends in site reliability engineering.
Read more →
Flektor

Flektor was a web application that allowed users the ability to create and "mashup" their own content (photos, videos, music, etc.) and share it via email, on social networking websites MySpace, Facebook, Blogger, Digg, eBay or on personal blogs. The company's website (Flektor.com) launched on April 2, 2007, and over 40,000 people began utilizing its features just one month later. Flektor closed down in January 2009. Flektor offered tools and widgets that included audio, video, photos, text, and approximately 100 effects, transitions and filters to be used with media. Users could create personalized slideshows, polls, postcards, and streaming video projects which the website calls "fleks". Flektor also offered Chat (used as a MySpace addon) and Movie Editor, which provided the ability to edit content and assets together. Users of Flektor could import media from websites like Photobucket and Google's YouTube, and then edit their content with the site's editing tools. Flektor's erstwhile competitors include Slide.com (founded by PayPal co-founder Max Levchin), RockYou!, Yahoo's JumpCut and Brightcove. == History == Flektor was created by Jason Rubin, Andy Gavin and former HBO executive Jason R. Kay. Both Rubin and Gavin spent most of their careers in the video game industry developing games for publishers like Electronic Arts, Universal Interactive Studios and Sony Computer Entertainment America. They founded a successful game development studio called Naughty Dog and were responsible for games such as Crash Bandicoot and Jak and Daxter. After selling Naughty Dog to Sony, Rubin focused on a comic book series called Iron and the Maiden before teaming up again with Gavin to venture into the web industry with Flektor. Jason Kay spent four years at Home Box Office, working as a consultant to the EVP of Business Development. They recruited former employee and then Naughty Dog Lead Programmer Scott Shumaker to lead the technology team along with Gavin. Ryan Evans joined shortly thereafter, spearheading product development. Flektor is based in Culver City, California. In May 2007, the company was sold to Fox Interactive Media, which is a division of News Corp., for more than $20 million. The deal coincided with Fox's acquisition of Photobucket, an image-hosting and sharing website. Fox Interactive Media already holds possession of MySpace, IGN Entertainment, FOXSports.com, AmericanIdol.com and Rotten Tomatoes. After the acquisition, Rubin, Gavin and Kay departed, leaving the studio in the hands of Shumaker and Evans. In the fall of 2007, Flektor partnered with its sister company, MySpace, and MTV to provide instant audience feedback via polls for the interactive MySpace/ MTV Presidential Dialogues series with presidential candidates Senator Barack Obama, Senator John McCain and John Edwards. Use of Flektor's polling system, enabled hosts John McLaughlin and Geoffrey Garin to cater their questions towards subjects of voter-interest. In the fall of 2008, Flektor built the official site for the 2008 Presidential debates, hosted at MyDebates. In January 2009, due to a company directive to focus on the core MySpace property, Fox Interactive announced that Flektor would be shut down, with some of its technology being incorporated into MySpace.
Read more →
Situational application

In computing, a situational application is "good enough" software created for a narrow group of users with a unique set of needs. The application typically (but not always) has a short life span, and is often created within the group where it is used, sometimes by the users themselves. As the requirements of a small team using the application change, the situational application often also continues to evolve to accommodate these changes. Although situational applications are specifically designed to embrace change, significant changes in requirements may lead to an abandonment of the situational application altogether – in some cases it is just easier to develop a new one than to evolve the one in use. == Characteristics == Situational applications are developed fast, easy to use, uncomplicated, and serve a unique set of requirements. They have a narrow focus on a specific business problem, and they are written in a way where if the business problem changes rapidly, so can the situational application. This contrasts with more common enterprise applications, which are designed to address a large set of business problems, require meticulous planning, and impose a sometimes-slow and often-meticulous change process. == Origination == Clay Shirky in his essay entitled "Situated Software" described a type of software that "...is designed for use by a specific social group, rather than for a generic set of "users"." IBM later morphed the term into "situational applications". == Evolution == The successful large-scale implementation of a situational application environment in an organization requires a strategy, mindset, methodology and support structure quite different from traditional application development. This is now evolving as more companies learn how to best leverage the ideas behind situational applications. In addition, the advent of cloud-based application development and deployment platforms makes the implementation of a comprehensive situational application environment much more feasible. == Examples == A structured wiki that can host wiki applications lends itself to creation of situational applications. Some mashups can also be considered situational applications. A forms application such as a Microsoft Access Database (MDB file) can be considered a situational application. The latest implementations of situational application environments include Longjump, Force.com and WorkXpress.
Read more →
Software component

A software component is a modular unit of software that encapsulates specific functionality. The desired characteristics of a component are reusability and maintainability. == Value == Components allow software developers to assemble software with reliable parts rather than writing code for every aspect. It makes implementation more like factory assembly than custom building. == Attributes == Desirable attributes of a component include but are not limited to: Cohesive – encapsulates related functionality Reusable Robust Substitutable – can be replaced by another component with the same interface Documented Tested == Third-party == Some components are built in-house by the same organization or team building the software system. Some are third-party, developed elsewhere and assembled into the software system. == Component-based software engineering == For large-scale systems, component-based development encourages a disciplined process to manage complexity. == Framework == Some components conform to a framework technology that allows them to be consumed in a well-known way. Examples include: CORBA, COM, Enterprise JavaBeans, and the .NET Framework. == Modeling == Component design is often modeled visually. In Unified Modeling Language (UML) 2.0 a component is shown as a rectangle, and an interface is shown as a lollipop to indicate a provided interface and as a socket to indicate consumption of an interface. == History == The idea of reusable software components was promoted by Douglas McIlroy in his presentation at the NATO Software Engineering Conference of 1968. (One goal of that conference was to resolve the so-called software crisis of the time.) In the 1970s, McIlroy put this idea into practice with the addition of the pipeline feature to the Unix operating system. Brad Cox refined the concept of a software component in the 1980s. He attempted to create an infrastructure and market for reusable third-party components by inventing the Objective-C programming language. IBM introduced System Object Model (SOM) in the early 1990s. Microsoft introduced Component Object Model (COM) in the early 1990s. Microsoft built many domain-specific component technologies on COM, including Distributed Component Object Model (DCOM), Object Linking and Embedding (OLE), and ActiveX.
Read more →
Virtual Woman

Virtual Woman is a software program that has elements of a chatbot, virtual reality, artificial intelligence, a video game, and a virtual human. It claims to be the oldest form of virtual life in existence, as it has been distributed since the late 1980s. Recent releases of the program can update their intelligence by connecting online and downloading newer personalities and histories. == Program play == When Virtual Woman starts, the user is presented with a list of options and then may choose their Virtual Woman's ethnic type, personality, location, clothing, etc. or load a pre-built Virtual Woman from a Digital DNA file. Once the options are determined, the user is presented with a 3-D animated Virtual Woman of their selection and then can engage them in conversation, progressing in a manner similar to that of its predecessor, ELIZA and its successors, the chatbots. In most versions of Virtual Woman, this is done through the keyboard, but some versions also support voice input. == In popular culture == Software sales and usage statistics from private companies are difficult to verify. WinSite, an independent Internet shareware distribution site that does publish public download counts, has for some time now listed some version of Virtual Woman in their top three shareware downloads of all time with well over seven hundred thousand downloads. == Compadre == The group of beta testers and advisers for Virtual Woman are referred to as Compadre and have their own beta testing site and forum. == Criticisms == As Virtual Woman has developed the ability to conduct longer and more realistic interactions, particularly in recent beta releases, criticism has arisen that this may lead some users to social isolation, or to use the program as a substitute for real human interaction. However, these are criticisms that have been leveled at all video games and at the use of the Internet itself. == Release history == Versions of Virtual Woman with rough release dates and PC platforms for which they were designed: Virtual Woman (????) (DOS) Virtual Woman for Windows (1991) (Windows 3.0) Virtual Woman 95 (1995) (Windows 3X, Windows 95) Virtual Woman 98 (1998) (Windows 3X, Windows 95) Virtual Woman 2000 (2000) (Windows 95+) Virtual Woman Millennium (Windows 95, XP) Virtual Woman Net ( Windows XP/Vista specific)
Read more →
List of Fortran software and tools

This is a list of Fortran software and tools, including IDEs, compilers, libraries, debugging tools, numerical and scientific computing tools, and related projects. == Fortran compilers == Absoft Pro Fortran — Absoft Pro Fortran is discontinued and ran on Linux and macOS AOCC — from AMD Classic Flang — part of the LLVM Project LLVM Flang — part of the LLVM Project Fortran 77 — Fortran 77 was developed by Digital Equipment Corporation, it is discontinued. G95 – portable open-source Fortran 95 compiler GCC (GNU Fortran) PGI compilers – NVIDIA developed compilers after acquiring The Portland Group IBM XL Fortran — IBM XL Fortran is current and runs on Linux (Power/AIX) and integrates with Eclipse Intel Fortran Compiler – part of Intel OneAPI HPC toolkit LFortran — LFortran is current, cross-platform, and has IDE support. MinGW – cross compiler and forked into Mingw-w64 nAG Fortran Compiler - from nAG Open64 — Open64 is an open-source compiler that has been terminated and ran on Linux Open Watcom — Open Watcom is current, runs on MS-DOS and OS/2, and has IDE support. Oracle Fortran — Oracle Fortran is discontinued, ran on Linux and Solaris. ROSE — source-to-source compiler framework developed at Lawrence Livermore National Laboratory Silverfrost FTN95 — FTN95 from Silverfrost is current, runs on Windows, and has IDE support. == Integrated development environments (IDEs) and editors == Code::Blocks — supports Fortran with plugins Eclipse IDE — with Fortran support via Photran Emacs — extensible text editor with built-in Fortran modes and support for modern tooling via language servers Geany — lightweight cross-platform IDE based on GTK IntelliJ IDEA — cross-platform IDE by JetBrains with Fortran pluggin KDevelop — KDE-based IDE NetBeans — Apache software foundation IDE with Fortran configuration OpenWatcom — IDE and compiler suite for C, C++, and Fortran Simply Fortran — standalone Fortran IDE for Windows, Linux, and macOS Vim — modal text editor with native Fortran syntax support and extensive plugin-based development features Visual Studio — with Intel Fortran integration Visual Studio Code — supports Fortran via extensions == Mathematical libraries == == Scientific libraries == ABINIT — software suite to calculate optical, mechanical, vibrational, and other observable properties of materials Cantera — chemical kinetics, thermodynamics, and transport tool suite CERN Program Library — collection of Fortran libraries for physics applications from CERN CP2K — quantum chemistry and solid-state physics software package for atomistic simulations Dalton — molecular electronic structure program FFTPACK — subroutines for the fast Fourier transform Kinetic PreProcessor – open-source software tool used in atmospheric chemistry MESA — Modules for Experiments in Stellar Astrophysics Nek5000 — MPI parallel higher-order spectral element CFD solver NWChem — open-source high-performance computational chemistry software Octopus — real-space Time-Dependent Density Functional Theory code MODTRAN – model atmospheric propagation of electromagnetic radiation MOLCAS — quantum chemistry software package for multiconfigurational electronic structure calculations NOVAS – software library for astrometry-related numerical computations Physics Analysis Workstation – data analysis and graphical presentation in high-energy physics Quantum ESPRESSO — integrated suite for electronic-structure calculations and materials modeling SIESTA — first-principles materials simulation code using density functional theory Tinker — software tools for molecular design == Debugging and performance tools == GDB — GNU Debugger with Fortran support Valgrind — memory debugging and profiling tool VTune Profiler — performance analysis tool Allinea Forge — debugger and profiler for HPC applications == Build and package management == Autotools — build system supporting Fortran projects CMake — cross-platform build system supporting Fortran Make — build automation tool Spack — package manager for HPC software including Fortran libraries == Machine learning and AI libraries == Athena Fiats (Functional Inference And Training for Surrogates) FNN (Fortran Neural Network) FortNN Fortran-TF-lib (Fortran interface to TensorFlow) FTorch (Fortran interface to PyTorch) MlFortran RoseNNa == Parallel and high-performance computing tools == MPI Fortran bindings — standard interface for distributed-memory parallelism OpenMP — shared-memory parallel programming support through compiler directives Coarray Fortran — parallel programming model introduced in Fortran 2008 ScaLAPACK — parallel linear algebra package built on top of LAPACK == Testing frameworks == FUnit — open-source unit testing framework developed at NASA’s Langley Research Center, for Fortran 90, 95, and 2003. pFUnit — unit testing framework for Fortran, modeled after JUnit == Documentation and code analysis tools == FORD — automatic documentation generator for modern Fortran projects SQuORE — software quality and management platform with code analysis support Understand — static analysis and code comprehension tool for large Fortran projects
Read more →
Software diversity

Software diversity is a research field about the comprehension and engineering of diversity in the context of software. == Areas == The different areas of software diversity are discussed in surveys on diversity for fault-tolerance or for security. The main areas are: design diversity, n-version programming, data diversity for fault tolerance randomization software variability == Techniques == === Code transformations === It is possible to amplify software diversity through automated transformation processes that create synthetic diversity. A "multicompiler" is compiler embedding a diversification engine. A multi-variant execution environment (MVEE) is responsible for selecting the variant to execute and compare the output. Fred Cohen was among the very early promoters of such an approach. He proposed a series of rewriting and code reordering transformations that aim at producing massive quantities of different versions of operating systems functions. These ideas have been developed over the years and have led to the construction of integrated obfuscation schemes to protect key functions in large software systems. Another approach to increase software diversity of protection consists in adding randomness in certain core processes, such as memory loading. Randomness implies that all versions of the same program run differently from each other, which in turn creates a diversity of program behaviors. This idea was initially proposed and experimented by Stephanie Forrest and her colleagues. Recent work on automatic software diversity explores different forms of program transformations that slightly vary the behavior of programs. The goal is to evolve one program into a population of diverse programs that all provide similar services to users, but with a different code. This diversity of code enhances the protection of users against one single attack that could crash all programs at the same time. Transformation operators include: code layout randomization: reorder functions in code globals layout randomization: reorder and pad globals stack variable randomization: reorder variables in each stack frame heap layout randomization === Natural software diversity === It is known that some functionalities are available in multiple interchangeable implementations. This natural diversity can be exploited, for example it has been shown valuable to increase security in cloud systems.
Read more →