Confirmatory blockmodeling is a deductive approach in blockmodeling, where a blockmodel (or part of it) is prespecify before the analysis, and then the analysis is fit to this model. When only a part of analysis is prespecify (like individual cluster(s) or location of the block types), it is called partially confirmatory blockmodeling. This is so-called indirect approach, where the blockmodeling is done on the blockmodel fitting (e.g., a priori hypothesized blockmodel). Opposite approach to the confirmatory blockmodeling is an inductive exploratory blockmodeling.
ELIZA
ELIZA is an early natural language processing computer program developed from 1964 to 1967 at MIT by Joseph Weizenbaum. Created to explore communication between humans and machines, ELIZA simulated conversation by using a pattern matching and substitution methodology that gave users an illusion of understanding on the part of the program, but gave no response that could be considered really understanding what was being said by either party. Whereas the ELIZA program itself was written (originally) in MAD-SLIP, the pattern matching directives that contained most of its language capability were provided in separate "scripts", represented in a Lisp-like expression. The most famous script, DOCTOR, simulated a psychotherapist of the Rogerian school (in which the therapist often reflects back the patient's words to the patient), and used rules, dictated in the script, to respond with non-directional questions to user inputs. As such, ELIZA was one of the first chatbots (originally "chatterbots") and one of the first programs capable of attempting the Turing test. Weizenbaum intended the program as a method to explore communication between humans and machines. He was surprised that some people, including his secretary, attributed human-like feelings to the computer program, a phenomenon that came to be called the ELIZA effect. Many academics believed that the program would be able to positively influence the lives of many people, particularly those with psychological issues, and that it could aid doctors working on such patients' treatment. While ELIZA was capable of engaging in discourse, it could not converse with true understanding. However, many early users were convinced of ELIZA's intelligence and understanding, despite Weizenbaum's insistence to the contrary. The original ELIZA source code had been missing since its creation in the 1960s, as it was not common to publish articles that included source code at that time. However, more recently the MAD-SLIP source code was discovered in the MIT archives and published on various platforms, such as the Internet Archive. The source code is of high historical interest since it demonstrates not only the specificity of programming languages and techniques at that time, but also the beginning of software layering and abstraction as a means of achieving sophisticated software programming. == Overview == Joseph Weizenbaum's ELIZA, running the DOCTOR script, created a conversational interaction somewhat similar to what might take place in the office of "a [non-directive] psychotherapist in an initial psychiatric interview" and to "demonstrate that the communication between man and machine was superficial". While ELIZA is best known for acting in the manner of a psychotherapist, the speech patterns are due to the data and instructions supplied by the DOCTOR script. ELIZA itself examined the text for keywords, applied values to said keywords, and transformed the input into an output; the script that ELIZA ran determined the keywords, set the values of keywords, and set the rules of transformation for the output. Weizenbaum chose to make the DOCTOR script in the context of psychotherapy to "sidestep the problem of giving the program a data base of real-world knowledge", allowing it to reflect back the patient's statements to carry the conversation forward. The result was a somewhat intelligent-seeming response that reportedly deceived some early users of the program. Weizenbaum named his program ELIZA after Eliza Doolittle, a working-class character in George Bernard Shaw's Pygmalion (also appearing in the musical My Fair Lady, which was based on the play and was hugely popular at the time). According to Weizenbaum, ELIZA's ability to be "incrementally improved" by various users made it similar to Eliza Doolittle, since Eliza Doolittle was taught to speak with an upper-class accent in Shaw's play. However, unlike the human character in Shaw's play, ELIZA is incapable of learning new patterns of speech or new words through interaction alone. Edits must be made directly to ELIZA's active script in order to change the manner by which the program operates. Weizenbaum first implemented ELIZA in his own SLIP list-processing language, where, depending upon the initial entries by the user, the illusion of human intelligence could appear, or be dispelled through several interchanges. Some of ELIZA's responses were so convincing that Weizenbaum and several others have anecdotes of users becoming emotionally attached to the program, occasionally forgetting that they were conversing with a computer. Weizenbaum's own secretary reportedly asked Weizenbaum to leave the room so that she and ELIZA could have a real conversation. Weizenbaum was surprised by this, later writing: "I had not realized ... that extremely short exposures to a relatively simple computer program could induce powerful delusional thinking in quite normal people." In 1966, interactive computing (via a teletype) was new. It was 11 years before the personal computer became familiar to the general public, and three decades before most people encountered attempts at natural language processing in Internet services like Ask.com or PC help systems such as Microsoft Office Clippit. Although those programs included years of research and work, ELIZA remains a milestone because it was the first time a programmer had attempted such a human-machine interaction with the goal of creating the illusion (however brief) of human–human interaction. At the ICCC 1972, ELIZA was brought together with another early artificial-intelligence program named PARRY for a computer-only conversation. While ELIZA was built to speak as a doctor, PARRY was intended to simulate a patient with schizophrenia. == Design and implementation == Weizenbaum originally wrote ELIZA in MAD-SLIP for CTSS on an IBM 7094 as a program to make natural-language conversation possible with a computer. To accomplish this, Weizenbaum identified five "fundamental technical problems" for ELIZA to overcome: the identification of key words, the discovery of a minimal context, the choice of appropriate transformations, the generation of responses in the absence of key words, and the provision of an editing capability for ELIZA scripts. Weizenbaum solved these problems and made ELIZA such that it had no built-in contextual framework or universe of discourse. However, this required ELIZA to have a script of instructions on how to respond to inputs from users. ELIZA starts its process of responding to an input by a user by first examining the text input for a "keyword". A "keyword" is a word designated as important by the acting ELIZA script, which assigns to each keyword a precedence number, or a RANK, designed by the programmer. If such words are found, they are put into a "keystack", with the keyword of the highest RANK at the top. The input sentence is then manipulated and transformed as the rule associated with the keyword of the highest RANK directs. For example, when the DOCTOR script encounters words such as "alike" or "same", it would output a message pertaining to similarity, in this case "In what way?", as these words had high precedence number. This also demonstrates how certain words, as dictated by the script, can be manipulated regardless of contextual considerations, such as switching first-person pronouns and second-person pronouns and vice versa, as these too had high precedence numbers. Such words with high precedence numbers are deemed superior to conversational patterns and are treated independently of contextual patterns. Following the first examination, the next step of the process is to apply an appropriate transformation rule, which includes two parts: the "decomposition rule" and the "reassembly rule". First, the input is reviewed for syntactical patterns in order to establish the minimal context necessary to respond. Using the keywords and other nearby words from the input, different disassembly rules are tested until an appropriate pattern is found. Using the script's rules, the sentence is then "dismantled" and arranged into sections of the component parts as the "decomposition rule for the highest-ranking keyword" dictates. The example that Weizenbaum gives is the input "You are very helpful", which is transformed to "I are very helpful". This is then broken into (1) empty (2) "I" (3) "are" (4) "very helpful". The decomposition rule has broken the phrase into four small segments that contain both the keywords and the information in the sentence. The decomposition rule then designates a particular reassembly rule, or set of reassembly rules, to follow when reconstructing the sentence. The reassembly rule takes the fragments of the input that the decomposition rule had created, rearranges them, and adds in programmed words to create a response. Using Weizenbaum's example previously stated, such a reassembly rule would take the fragments and apply them to the phrase "What makes
Outlook on the web
Outlook on the web (formerly Outlook Web App and Outlook Web Access) is a personal information manager web app from Microsoft. It is a web-based version of Microsoft Outlook, and is included in Exchange Server and Exchange Online (a component of Microsoft 365). It can be freely accessed from any web browser whether inside or outside an organization's network, and includes a web email client, a calendar tool, a contact manager, and a task manager. It also includes add-in integration, Skype on the web, and alerts as well as unified themes that span across all the web apps. == Purpose == Outlook on the web is available to Microsoft 365 (formerly Office 365) and Exchange Online subscribers, and is included with the on-premises Exchange Server, to enable users to connect to their email accounts via a web browser, without requiring the installation of Microsoft Outlook or other email clients. In case of Exchange Server, it is hosted on a local intranet and requires a network connection to the Exchange Server for users to work with e-mail, address book, calendars and task. The Exchange Online version, which can be bought either independently or through Office 365 licensing program, is hosted on Microsoft servers on the World Wide Web. == History == Outlook Web Access was created in 1995 by Microsoft Program Manager Thom McCann on the Exchange Server team. An early working version was demonstrated by Microsoft Vice President Paul Maritz at Microsoft's famous Internet summit in Seattle on December 27, 1995. The first customer version was shipped as part of the Exchange Server 5.0 release in early 1997. The first component to allow client-side scripts to issue HTTP requests (XMLHTTP) was originally written by the Outlook Web Access team. It soon became a part of Internet Explorer 5. Renamed XMLHttpRequest and standardized by the World Wide Web Consortium, it has since become one of the cornerstones of the Ajax technology used to build advanced web apps. Outlook Web Access was later renamed Outlook Web App in 2010. An update on August 4, 2015, renamed OWA to "Outlook on the web", often referred to in brief as simply "Outlook". == Components == === Mail === Mail is the webmail component of Outlook on the web. The default view is a three column view with folders and groups on the left, an email message list in the middle, and the selected message on the right. With the 2015 update, Microsoft introduced the ability to pin, sweep and archive messages, and undo the last action, as well as richer image editing features. It can connect to other services such as GitHub and Twitter through Office 365 Connectors. Actionable Messages in emails allows a user to complete a task from within the email, such as retweeting a Tweet on Twitter or setting a meeting date on a calendar. Outlook on the web supports S/MIME and includes features for managing calendars, contacts, tasks, documents (used with SharePoint or Office Web Apps), and other mailbox content. In the Exchange 2007 release, Outlook on the web (still called Outlook Web App at the time) also offers read-only access to documents stored in SharePoint sites and network UNC shares. === Calendar === Calendar is the calendaring component of Outlook on the web. With the update, Microsoft added a weather forecast directly in the Calendar, as well as icons (or "charms") as visual cues for an event. In addition, email reminders came to all events, and a special Birthday and Holiday event calendars are created automatically. Calendars can be shared and there are multiple views such as day, week, month, and today. Another view is work week which includes Mondays through Fridays in the calendar view. Calendar's "Board View" feature allows for a customizable calendar with widgets such as Goal, Calendar, Tasks and Tips. Calendar details can be added with HTML and rich-text editing, and files can be attached to calendar events and appointments. === People === People is the contact manager component of Outlook on the web. A user can search and edit existing contacts, as well as create new ones. Contacts can be placed into folders and duplicate contacts can be linked from multiple sources such as LinkedIn or Twitter. In Outlook Mail, a contact can be created by clicking on an email address sender, which pulls down a contact card with an add button to add to Outlook People. Contacts can be imported as well as placed into a list that can be utilized when composing an email in Outlook Mail. People can also sync with friends and connections lists on LinkedIn, Facebook, and Twitter. === To Do === To Do was originally launched as Tasks for Outlook Web App. Microsoft was slowly rolling out a preview of Tasks to its consumer-based Outlook.com service that in May 2015, was announced to be moving to the Office 365 infrastructure. It was initially a part of Calendar as a view. Microsoft has separated the services into its own web app in Outlook on the web. In a post on the Office Blogs in 2015, Microsoft announced that Outlook Web App would be renamed Outlook on the web and that Tasks would move under that brand. A user can create tasks, put them into categories, and move them to another folder. A feature added was the ability to set due days and sort and filter the tasks according to those criteria. The app provides the user with fields such as subject, start and end dates, percent complete, priority, and how much work was put into each task. Rich editing features like bold, italic, underline, numbering, and bullet points were also introduced. Tasks can be edited and categorized according to how the user wishes them to be sorted. == Removed features == Outlook on the web has had two interfaces available: one with a complete feature set (known as Premium) and one with reduced functionality (known as Light or sometimes Lite). Prior to Exchange 2010, the Premium client required Internet Explorer. Exchange 2000 and 2003 require Internet Explorer 5 and later, and Exchange 2007 requires Internet Explorer 6 and later. Exchange 2010 supports a wider range of web browsers: Internet Explorer 7 or later, Firefox 3.01 or later, Chrome, or Safari 3.1 or later. However, Exchange 2010 restricts its Firefox and Safari support to macOS and Linux. In Exchange 2013, these browser restrictions were lifted. In Exchange 2010 and earlier, the Light user interface is rendered for browsers other than Internet Explorer. The basic interface did not support search on Exchange Server 2003. In Exchange Server 2007, the Light interface supported searching mail items; managing contacts and the calendar was also improved. The 2010 version can connect to an external email account. The ability to add new accounts to Outlook on the web using the Connected accounts feature was removed in September 2018 and all connected accounts stopped synchronizing email the following month.
Recruitee
Tellent Recruitee is a cloud-based applicant tracking system (ATS) for talent acquisition owned by Tellent. It is used by internal HR teams for processes including job postings, candidate sourcing, reporting, and applicant tracking. == History == Perry Oostdam and Pawel Smoczyk founded Recruitee after working on a mobile gaming startup. The Recruitee was launched in August 2015. In September 2015, it received a seed funding round with participation from investors Robert Pijselman and Luc Brandts. Merger In February 2021, Recruitee and the Finnish HR software provider Sympa merged their operations, backed by the growth equity firm Providence Strategic Growth (PSG). Acquisition In 2022, the group acquired the French company Javelo and the German company kiwiHR. The parent company was subsequently renamed as Tellent while Recruitee renamed as Tellent Recruitee and continues to operate as a product unit within the Tellent group. == Platform == Tellent Recruitee is a customizable recruitment software. It functions as an ATS and talent acquisition platform and includes tools to create and publish job listings, source candidates, manage recruitment agencies, and track applicants through customizable pipelines. The interface allows drag-and-drop organization of candidates. The platform also includes features for team collaboration, such as shared notes, task assignments, and candidate evaluations. It also has integrated scheduling tools and automated email communication. Tellent Recruitee also provides analytics and reports on hiring and career site metrics. The software allows for customization of career site pages and application forms. It supports integrations with other HR and productivity software, such as WhatsApp, and has various AI functionalities to support with manual recruitment tasks.
SWIG
The Simplified Wrapper and Interface Generator (SWIG) is an open-source software tool used to connect computer programs or libraries written in C or C++ with scripting languages such as Lua, Perl, PHP, Python, R, Ruby, Tcl, and other language implementations like C#, Java, JavaScript, Go, D, OCaml, Octave, Scilab and Scheme. Output can also be in the form of XML. == Function == The aim is to allow the calling of native functions (that were written in C or C++) by other programming languages, passing complex data types to those functions, keeping memory from being inappropriately freed, inheriting object classes across languages, etc. The programmer writes an interface file containing a list of C/C++ functions to be made visible to an interpreter. SWIG will compile the interface file and generate code in regular C/C++ and the target programming language. SWIG will generate conversion code for functions with simple arguments; conversion code for complex types of arguments must be written by the programmer. The SWIG tool creates source code that provides the glue between C/C++ and the target language. Depending on the language, this glue comes in three forms: a shared library that an extant interpreter can link to as some form of extension module, or a shared library that can be linked to other programs compiled in the target language (for example, using Java Native Interface (JNI) in Java). a shared dynamic library source code that should be compiled and dynamically loaded (e.g. Node.js native extensions) SWIG is not used for calling interpreted functions by native code; this must be done by the programmer manually. == Example == SWIG wraps simple C declarations by creating an interface that closely matches the way in which the declarations would be used in a C program. For example, consider the following interface file: In this file, there are two functions sin() and strcmp(), a global variable Foo, and two constants STATUS and VERSION. When SWIG creates an extension module, these declarations are accessible as scripting language functions, variables, and constants respectively. In Python: == Purpose == There are two main reasons to embed a scripting engine in an existing C/C++ program: The program can then be customized far faster, via a scripting language instead of C/C++. The scripting engine may even be exposed to the end-user, so that they can automate common tasks by writing scripts. Even if the final product is not to contain the scripting engine, it may nevertheless be very useful for writing test scripts. There are several reasons to create dynamic libraries that can be loaded into extant interpreters, including: Provide access to a C/C++ library which has no equivalent in the scripting language. Write the whole program in the scripting language first, and after profiling, rewrite performance-critical code in C or C++. == History == SWIG is written in C and C++ and has been publicly available since February 1996. The initial author and main developer was David M. Beazley who developed SWIG while working as a graduate student at Los Alamos National Laboratory and the University of Utah and while on the faculty at the University of Chicago. Development is currently supported by an active group of volunteers led by William Fulton. SWIG has been released under a GNU General Public License. == Google Summer of Code == SWIG was a successful participant of Google Summer of Code in 2008, 2009, 2012. In 2008, SWIG got four slots. Haoyu Bai spent his summers on SWIG's Python 3.0 Backend, Jan Jezabek worked on Support for generating COM wrappers, Cheryl Foil spent her time on Comment 'Translator' for SWIG, and Maciej Drwal worked on a C backend. In 2009, SWIG again participated in Google Summer of Code. This time four students participated. Baozeng Ding worked on a Scilab module. Matevz Jekovec spent time on C++0x features. Ashish Sharma spent his summer on an Objective-C module, Miklos Vajna spent his time on PHP directors. In 2012, SWIG participated in Google Summer of Code. This time four out of five students successfully completed the project. Leif Middelschulte worked on a C target language module. Swati Sharma enhanced the Objective-C module. Neha Narang added the new module on JavaScript. Dmitry Kabak worked on source code documentation and Doxygen comments. == Alternatives == For Python, similar functionality is offered by SIP, Pybind11, and Boost's Boost.python library. == Projects using SWIG == ZXID (Apache License, Version 2.0) Symlabs SFIS (commercial) LLDB GNU Radio up to (including) version 3.8.x.x; later versions use Pybind11 Xapian TensorFlow Apache SINGA QuantLib Babeltrace
Cheekd
Cheekd is a dating app based in New York City. It was founded in 2010 by Lori Cheek. == History == The service debuted with the name "Cheek'd". Founder Lori Cheek appeared on the television program, Shark Tank in February 2014, but did not succeed in obtaining funding from any of the five judges. She said Cheek’d only had 1000 subscribers at that time. === Business card model === Cheek'd offered two plans, paid and free. For $25, subscribers got a set of 50 business cards that could be given out once someone caught their eye. Each card had a phrase, an online code, and a URL to the subscriber's account. Recipients could look up the giver's profile. In addition to purchasing cards, there was a $9.95 monthly membership fee. === Smartphone app === In 2015, the service's name changed from "Cheek'd" to "Cheekd". The new app used Bluetooth technology to alert users whenever a compatible user was within a 30-foot radius, instead of using cards. == Patent lawsuit == The original business card-based model for Cheekd had been claimed as a patented process by Lori Cheek, as U.S. patent 8,543,465. In September 2017, a complaint was filed, alleging that the idea was not original to Lori Cheek. Cheek responded, stating that the complaint was baseless, and a complete fabrication. The lawsuit Pirri v. Cheek was dismissed in a pre-trial conference in New York's Federal Court on April 5, 2018.
Bring your own encryption
Bring your own encryption (BYOE), also known as bring your own key (BYOK), is a cloud computing security model that allows cloud service customers to use their own encryption software and manage their own encryption keys. == Overview == BYOE enables cloud service customers to utilize a virtual instance of their encryption software alongside their cloud-hosted business applications to encrypt their data. In this model, hosted business applications are configured to process all data through the encryption software. This software then writes the ciphertext version of the data to the cloud service provider's physical data store and decrypts ciphertext data upon retrieval requests. This approach provides enterprises with control over their keys and the ability to generate their own master key using internal hardware security modules (HSM), which are then transmitted to the cloud provider's HSM. When the data is no longer needed, such as when users discontinue the cloud service, the keys can be deleted, rendering the encrypted data permanently inaccessible. This practice is known as crypto-shredding. == Potential Advantages == Organizations can store data with unique encryption that only they can access. Multiple organizations can share the same hardware infrastructure via cloud services like Amazon Web Services (AWS) or Google Cloud while maintaining encryption to comply with regulations such as HIPAA. == Potential Challenges == Resource utilization may be higher compared to traditional encryption practices when multiple users share the same hardware and use their own encryption. Efforts to minimize resource utilization issues may potentially impact security benefits.