AI Chat To Pdf

AI Chat To Pdf — independent reviews, comparisons, pricing and step-by-step guides on Aizhi.

  • AirPair

    AirPair

    AirPair is a service and eponymous company that connects people who need help with programming issues (usually, programmers at small technology companies or at finance companies that use technology products) and people who can help them. Unlike services such as oDesk and Elance, AirPair is not a service for outsourcing programming tasks, but rather a service that facilitates one-off knowledge transfers from people with highly specialized knowledge of particular technology stacks or programming issues to people who are in need of specialized help. == History == AirPair launched in March 2013, with founder Jonathon Kresner, who hails from Australia, working full-time, and it soon hired three other part-time developers to work alongside him. Kresner had previously founded two other startups: Preparty, a social invitation and event-booking service based in Australia, and ClimbFind, an online rock-climbing community that reached a million users. Kresner was inspired to work on AirPair because he saw the need for outside expert assistance with programming issues arise regularly at these startups. In November 2013, founder Kresner describes the company's initial success at bootstrapping itself to "Ramen profitability" in a blog post. In December 2013, AirPair was accepted into the Winter 2014 Y Combinator batch. In March 2014, AirPair announced it would launch partnerships with Stripe, Twilio, and other companies that had their own application programming interfaces, allowing developers having trouble with the APIs to seek help over AirPair from experts on the APIs. AirPair presented at the Y Combinator Winter 2014 Demo Day on March 25, 2014, and successfully raised over $1 million within the next 48 hours. == Reception == A review of AirPair by Will Lam stressed that because payment was based on time rather than results, it was important to use it for clearly thought-out questions where one had high confidence that the session would help. Dennis Beatty, who met AirPair founder Jonathon Kresner in March 2014, wrote in April 2014 a glowing review of AirPair's vision of connecting people and its business success. AirPair has been compared with other peer-to-peer coding help sites such as Codementor and HackHands.

    Read more →
  • Recruitee

    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.

    Read more →
  • Cloudlet

    Cloudlet

    A cloudlet is a mobility-enhanced small-scale cloud datacenter that is located at the edge of the Internet. The main purpose of the cloudlet is supporting resource-intensive and interactive mobile applications by providing powerful computing resources to mobile devices with lower latency. It is a new architectural element that extends today's cloud computing infrastructure. It represents the middle tier of a 3-tier hierarchy: mobile device - cloudlet - cloud. A cloudlet can be viewed as a data center in a box whose goal is to bring the cloud closer. The cloudlet term was first coined by M. Satyanarayanan, Victor Bahl, Ramón Cáceres, and Nigel Davies, and a prototype implementation is developed by Carnegie Mellon University as a research project. The concept of cloudlet is also known as follow me cloud, and mobile micro-cloud. == Motivation == Many mobile services split the application into a front-end client program and a back-end server program following the traditional client-server model. The front-end mobile application offloads its functionality to the back-end servers for various reasons such as speeding up processing. With the advent of cloud computing, the back-end server is typically hosted at the cloud datacenter. Though the use of a cloud datacenter offers various benefits such as scalability and elasticity, its consolidation and centralization lead to a large separation between a mobile device and its associated datacenter. End-to-end communication then involves many network hops and results in high latencies and low bandwidth. For the reasons of latency, some emerging mobile applications require cloud offload infrastructure to be close to the mobile device to achieve low response time. In the ideal case, it is just one wireless hop away. For example, the offload infrastructure could be located in a cellular base station or it could be LAN-connected to a set of Wi-Fi base stations. The individual elements of this offload infrastructure are referred to as cloudlets. == Applications == Cloudlets aim to support mobile applications that are both resource-intensive and interactive. Augmented reality applications that use head-tracked systems require end-to-end latencies of less than 16 ms. Cloud games with remote rendering also require low latencies and high bandwidth. Wearable cognitive assistance systems combine devices such as Google Glass with cloud-based processing to guide users through complex tasks. This futuristic genre of applications is characterized as “astonishingly transformative” by the report of the 2013 NSF Workshop on Future Directions in Wireless Networking. These applications use cloud resources in the critical path of real-time user interaction. Consequently, they cannot tolerate end-to-end operation latencies of more than a few tens of milliseconds. Apple Siri and Google Now which perform compute-intensive speech recognition in the cloud, are further examples in this emerging space. == Cloudlet vs Cloud == There is significant overlap in the requirements for cloud and cloudlet. At both levels, there is the need for: (a) strong isolation between untrusted user-level computations; (b) mechanisms for authentication, access control, and metering; (c) dynamic resource allocation for user-level computations; and, (d) the ability to support a very wide range of user-level computations, with minimal restrictions on their process structure, programming languages or operating systems. At a cloud datacenter, these requirements are met today using the virtual machine (VM) abstraction. For the same reasons they are used in cloud computing today, VMs are used as an abstraction for cloudlets. Meanwhile, there are a few but important differentiators between cloud and cloudlet. === Rapid provisioning === Different from cloud data centers that are optimized for launching existing VM images in their storage tier, cloudlets need to be much more agile in their provisioning. Their association with mobile devices is highly dynamic, with considerable churn due to user mobility. A user from far away may unexpectedly show up at a cloudlet (e.g., if he just got off an international flight) and try to use it for an application such as a personalized language translator. For that user, the provisioning delay before he is able to use the application impacts usability. === VM handoff across cloudlets === If a mobile device user moves away from the cloudlet he is currently using, the interactive response will degrade as the logical network distance increases. To address this effect of user mobility, the offloaded services on the first cloudlet need to be transferred to the second cloudlet maintaining end-to-end network quality. This resembles live migration in cloud computing but differs considerably in a sense that the VM handoff happens in Wide Area Network (WAN). == OpenStack++ == Since the cloudlet model requires reconfiguration or additional deployment of hardware/software, it is important to provide a systematic way to incentivise the deployment. However, it can face a classic bootstrapping problem. Cloudlets need practical applications to incentivize cloudlet deployment. However, developers cannot heavily rely on cloudlet infrastructure until it is widely deployed. To break this deadlock and bootstrap the cloudlet deployment, researchers at Carnegie Mellon University proposed OpenStack++ that extends OpenStack to leverage its open ecosystem. OpenStack++ provides a set of cloudlet-specific APIs as OpenStack extensions. == Commercial implementations and standardization effort == By 2015 cloudlet based applications were commercially available. In 2017 the National Institute of Standards and Technology published draft standards for fog computing in which cloudlets were defined as nodes on the fog architecture.

    Read more →
  • SWIG

    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

    Read more →
  • Medical imaging

    Medical imaging

    Medical imaging is the technique and process of imaging the interior of a body for clinical analysis and medical intervention, as well as visual representation of the function of some organs or tissues (physiology). Medical imaging seeks to reveal internal structures hidden by the skin and bones, as well as to diagnose and treat disease. Medical imaging also establishes a database of normal anatomy and physiology to make it possible to identify abnormalities. Although imaging of removed organs and tissues can be performed for medical reasons, such procedures are usually considered part of pathology instead of medical imaging. Measurement and recording techniques that are not primarily designed to produce images, such as electroencephalography (EEG), magnetoencephalography (MEG), electrocardiography (ECG), and others, represent other technologies that produce data susceptible to representation as a parameter graph versus time or maps that contain data about the measurement locations. In a limited comparison, these technologies can be considered forms of medical imaging in another discipline of medical instrumentation. As of 2010, 5 billion medical imaging studies had been conducted worldwide. Radiation exposure from medical imaging in 2006 made up about 50% of total ionizing radiation exposure in the United States. Medical imaging equipment is manufactured using technology from the semiconductor industry, including CMOS integrated circuit chips, power semiconductor devices, sensors such as image sensors (particularly CMOS sensors) and biosensors, and processors such as microcontrollers, microprocessors, digital signal processors, media processors and system-on-chip devices. As of 2015, annual shipments of medical imaging chips amount to 46 million units and $1.1 billion. The term "noninvasive" is used to denote a procedure where no instrument is introduced into a patient's body, which is the case for most imaging techniques used. == History == In 1972, engineer Godfrey Hounsfield from the British company EMI invented the X-ray computed tomography device for head diagnosis, which is commonly referred to as computed tomography (CT). The CT nucleus method is based on the projecting X-rays through a section of the human head, which are then processed by computer to reconstruct the cross-sectional image, known as image reconstruction. In 1975, EMI successfully developed a CT device for the entire body, enabling the clear acquisition of tomographic images of various parts of the human body. This revolutionary diagnostic technique earned Hounsfield and physicist Allan Cormack the Nobel Prize in Physiology or Medicine in 1979. Digital image processing technology for medical applications was inducted into the Space Foundation's Space Technology Hall of Fame in 1994. By 2010, over 5 billion medical imaging studies had been conducted worldwide. Radiation exposure from medical imaging in 2006 accounted for about 50% of total ionizing radiation exposure in the United States. Medical imaging equipment is manufactured using technology from the semiconductor industry, including CMOS integrated circuit chips, power semiconductor devices, sensors such as image sensors (particularly CMOS sensors) and biosensors, as well as processors like microcontrollers, microprocessors, digital signal processors, media processors and system-on-chip devices. As of 2015, annual shipments of medical imaging chips reached 46 million units, generating a market value of $1.1 billion. == Types == In the clinical context, "invisible light" medical imaging is generally equated to radiology or "clinical imaging". "Visible light" medical imaging involves digital video or still pictures that can be seen without special equipment. Dermatology and wound care are two modalities that use visible light imagery. Interpretation of medical images is generally undertaken by a physician specialising in radiology known as a radiologist; however, this may be undertaken by any healthcare professional who is trained and certified in radiological clinical evaluation. Increasingly interpretation is being undertaken by non-physicians, for example radiographers frequently train in interpretation as part of expanded practice. Diagnostic radiography designates the technical aspects of medical imaging and in particular the acquisition of medical images. The radiographer (also known as a radiologic technologist) is usually responsible for acquiring medical images of diagnostic quality; although other professionals may train in this area, notably some radiological interventions performed by radiologists are done so without a radiographer. As a field of scientific investigation, medical imaging constitutes a sub-discipline of biomedical engineering, medical physics or medicine depending on the context: Research and development in the area of instrumentation, image acquisition (e.g., radiography), modeling and quantification are usually the preserve of biomedical engineering, medical physics, and computer science; Research into the application and interpretation of medical images is usually the preserve of radiology and the medical sub-discipline relevant to medical condition or area of medical science (neuroscience, cardiology, psychiatry, psychology, etc.) under investigation. Many of the techniques developed for medical imaging also have scientific and industrial applications. === Radiography === Two forms of radiographic images are in use in medical imaging. Projection radiography and fluoroscopy, with the latter being useful for catheter guidance. These 2D techniques are still in wide use despite the advance of 3D tomography due to the low cost, high resolution, and depending on the application, lower radiation dosages with 2D technique. This imaging modality uses a wide beam of X-rays for image acquisition and is the first imaging technique available in modern medicine. Fluoroscopy produces real-time images of internal structures of the body in a similar fashion to radiography, but employs a constant input of X-rays, at a lower dose rate. Contrast media, such as barium, iodine, and air are used to visualize internal organs as they work. Fluoroscopy is also used in image-guided procedures when constant feedback during a procedure is required. An image receptor is required to convert the radiation into an image after it has passed through the area of interest. Early on, this was a fluorescing screen, which gave way to an Image Amplifier (IA) which was a large vacuum tube that had the receiving end coated with cesium iodide, and a mirror at the opposite end. Eventually the mirror was replaced with a TV camera. Projectional radiographs, more commonly known as X-rays, are often used to determine the type and extent of a fracture as well as for detecting pathological changes in the lungs. With the use of radio-opaque contrast media, such as barium, they can also be used to visualize the structure of the stomach and intestines – this can help diagnose ulcers or certain types of colon cancer. === Magnetic resonance imaging === A magnetic resonance imaging instrument (MRI scanner), or "nuclear magnetic resonance (NMR) imaging" scanner as it was originally known, uses powerful magnets to polarize and excite hydrogen nuclei (i.e., single protons) of water molecules in human tissue, producing a detectable signal that is spatially encoded, resulting in images of the body. The MRI machine emits a radio frequency (RF) pulse at the resonant frequency of the hydrogen atoms on water molecules. Radio frequency antennas ("RF coils") send the pulse to the area of the body to be examined. The RF pulse is absorbed by protons, causing their direction with respect to the primary magnetic field to change. When the RF pulse is turned off, the protons "relax" back to alignment with the primary magnet and emit radio waves in the process. This radio-frequency emission from the hydrogen atoms on water is what is detected and reconstructed into an image. The resonant frequency of a spinning magnetic dipole (of which protons are one example) is called the Larmor frequency and is determined by the strength of the main magnetic field and the chemical environment of the nuclei of interest. MRI uses three electromagnetic fields: a very strong (typically 1.5 to 3 teslas) static magnetic field to polarize the hydrogen nuclei, called the primary field; gradient fields that can be modified to vary in space and time (on the order of 1 kHz) for spatial encoding, often simply called gradients; and a spatially homogeneous radio-frequency (RF) field for manipulation of the hydrogen nuclei to produce measurable signals, collected through an RF antenna. Like CT, MRI traditionally creates a two-dimensional image of a thin "slice" of the body and is therefore considered a tomographic imaging technique. Modern MRI instruments are capable of producing images in the form of 3D blocks, which may be considered a generalization of the single-slice

    Read more →
  • SEMAT

    SEMAT

    SEMAT (Software Engineering Method and Theory) is an initiative to reshape software engineering such that software engineering qualifies as a rigorous discipline. The initiative was launched in December 2009 by Ivar Jacobson, Bertrand Meyer, and Richard Soley with a call for action statement and a vision statement. The initiative was envisioned as a multi-year effort for bridging the gap between the developer community and the academic community and for creating a community giving value to the whole software community. The work is now structured in four different but strongly related areas: Practice, Education, Theory, and Community. The Practice area primarily addresses practices. The Education area is concerned with all issues related to training for both the developers and the academics including students. The Theory area is primarily addressing the search for a General Theory in Software Engineering. Finally, the Community area works with setting up legal entities, creating websites and community growth. It was expected that the Practice area, the Education area and the Theory area would at some point in time integrate in a way of value to all of them: the Practice area would be a "customer" of the Theory area, and direct the research to useful results for the developer community. The Theory area would give a solid and practical platform for the Practice area. And, the Education area would communicate the results in proper ways. == Practice area == The first step was here to develop a common ground or a kernel including the essence of software engineering – things we always have, always do, always produce when developing software. The second step was envisioned to add value on top of this kernel in the form of a library of practices to be composed to become specific methods, specific for all kinds of reasons such as the preferences of the team using it, kind of software being built, etc. The first step is as of this writing just about to be concluded. The results are a kernel including universal elements for software development – called the Essence Kernel, and a language – called the Essence Language - to describe these elements (and elements built on top of the kernel (practices, methods, and more). Essence, including both the kernel and language, has been published as an OMG standard in beta status in July 2013 and is expected to become a formally adopted standard in early 2014. The second step has just started, and the Practice area will be divided into a number of separate but interconnected tracks: the practice (library track), the tool track are so far identified and work has started or is about to get started. The practice track is currently working on a Users Guide. == Education area == The area focuses on leveraging the work of SEMAT in software engineering education, both within academia and industry. It promotes global education based on a common ground called Essence. The area's target groups are instructors such as university professors and industrial coaches as well as their students and learning practitioners. The goal of the area is to create educational courses and course materials that are internationally viable, identify pedagogical approaches that are appropriate and effective for specific target groups and disseminate experience and lessons learned. The area includes members from a number of universities and institutes worldwide. Most members have already been involved in leveraging aspects of SEMAT in the context of their software engineering courses. They are gathering their resources and starting a common venture towards defining a new generation of SEMAT-powered software engineering curricula. As of 2018, some studies of utilizing Essence in educational settings exist. One example of the use of Essence in university education was a software engineering course carried out in Norwegian University of Science and Technology. A study was conducted by introducing Essence into a project-based software engineering course, with the aim of understanding what difficulties the students faced in using Essence, and whether they considered it to have been useful. The results indicated that Essence could also be useful for novice software engineers by (1) encouraging them to look up and study new practices and methods in order to create their own, (2) encouraging them to adjust their way-of-working reflectively and in a situation-specific manner, (3) helping them structure their way of working. The findings of another study introducing students to Essence through a digital game supported these findings: the students felt that Essence will be useful to them in future, real-world projects, and that they wish to utilize it in them. == Theory area == An important part of SEMAT is that a general theory of software engineering is planned to emerge with significant benefits. A series of workshops held under the title SEMAT Workshop on a General Theory of Software Engineering (GTSE) are a key component in awareness building around general theories. In addition to community awareness building, SEMAT also aims to contribute with a specific general theory of software engineering. This theory should be solidly based on the SEMAT Essence language and kernel, and should support software engineering practitioners' goal-oriented decision making. As argued elsewhere, such support is predicated on the predictive capabilities of the theory. Thus, the SEMAT Essence should be augmented to allow the prediction of critical software engineering phenomena. The GTSE workshop series assists in the development of the SEMAT general software engineering theory by engaging a larger community in the search for, development of, and evaluation of promising theories, which may be used as a base for the SEMAT theory. == Organizational structure == === Main organization === SEMAT is chaired by Sumeet S. Malhotra of Tata Consultancy Services. The CEO of the organization is Ste Nadin of Fujitsu. The Executive Management Committee of SEMAT are Ivar Jacobson, Ste Nadin, Sumeet S. Malhotra, Paul E. McMahon, Michael Goedicke and Cecile Peraire. === Japan Chapter === Japan Chapter was established in April 2013, and it has more than 250 members as of November 2013. Member activities include carrying out seminars about SEMAT, considering utilization of SEMAT Essence for integrating different requirements engineering techniques and body of knowledges (BoKs), and translating articles into Japanese. === Korea Chapter === The chapter was inaugurated with about 50 members in October 2013. Member activities include: 2e Consulting started rewriting their IT service engagement methods using the Essence kernel, and uEngine Solutions started developing a tool to orchestrate Essence-kernel based practices into a project method. Korean government supported KAIST to conduct research in Essence. === Latin American Chapter === Semat Latin American Chapter was created in August 2011 in Medellin (Colombia) by Ivar Jacobson during the Latin American Software Engineering Symposium. This Chapter has 9 Executive Committee members from Colombia, Venezuela, Peru, Brazil, Argentina, Chile, and Mexico, chaired by Dr. Carlos Zapata from Colombia. More than 80 people signed the initial declaration of the Chapter and nowadays the Chapter members are in charge of disseminating the Semat ideas in all Latin America. Chapter members have participated in various Latin American conferences, including the Latin American Conference on Informatics (CLEI), the Ibero American Software Engineering and Knowledge Engineering Journeys (JIISIC), the Colombian Computing Conference (CCC), and the Chilean Computing Meeting (ECC). The Chapter contributed in the submission sent in response to the OMG call for proposals and currently studies didactic strategies for teaching the Semat kernel by games, theoretical studies about some kernel elements, and practical representations of several software development and quality methods by using the Semat kernel. Some of the members also translated the Essence book and some other Semat materials and papers into Spanish. === Russia Chapter === Russian Chapter has about 20 members. A few universities have incorporated SEMAT in their training courses , including Moscow State University, Moscow Institute of Physics and Technology, Higher School of Economics, Moscow State University of Economics, Statistics, and Informatics. The chapter and some commercial companies are carrying out seminars about SEMAT. INCOSE Russian Chapter is working on an extension of SEMAT to systems engineering. EC-leasing is working on an extension of the Kernel for Software Life Cycle. Russian Chapter attended in two conferences: Actual Problems of System and Software Engineering and SECR with SEMAT section and articles. Translation of the Essence book into Russian is in progress. == Practical Applications of SEMAT == Ideas developed by the SEMAT community have been applied by both industry and ac

    Read more →
  • View model

    View model

    A view model or viewpoints framework in systems engineering, software engineering, and enterprise engineering is a framework which defines a coherent set of views to be used in the construction of a system architecture, software architecture, or enterprise architecture. A view is a representation of the whole system from the perspective of a related set of concerns. Since the early 1990s there have been a number of efforts to prescribe approaches for describing and analyzing system architectures. A result of these efforts have been to define a set of views (or viewpoints). They are sometimes referred to as architecture frameworks or enterprise architecture frameworks, but are usually called "view models". Usually a view is a work product that presents specific architecture data for a given system. However, the same term is sometimes used to refer to a view definition, including the particular viewpoint and the corresponding guidance that defines each concrete view. The term view model is related to view definitions. == Overview == The purpose of views and viewpoints is to enable humans to comprehend very complex systems, to organize the elements of the problem and the solution around domains of expertise and to separate concerns. In the engineering of physically intensive systems, viewpoints often correspond to capabilities and responsibilities within the engineering organization. Most complex system specifications are so extensive that no single individual can fully comprehend all aspects of the specifications. Furthermore, we all have different interests in a given system and different reasons for examining the system's specifications. A business executive will ask different questions of a system make-up than would a system implementer. The concept of viewpoints framework, therefore, is to provide separate viewpoints into the specification of a given complex system in order to facilitate communication with the stakeholders. Each viewpoint satisfies an audience with interest in a particular set of aspects of the system. Each viewpoint may use a specific viewpoint language that optimizes the vocabulary and presentation for the audience of that viewpoint. Viewpoint modeling has become an effective approach for dealing with the inherent complexity of large distributed systems. Architecture description practices, as described in IEEE Std 1471-2000, utilize multiple views to address several areas of concerns, each one focusing on a specific aspect of the system. Examples of architecture frameworks using multiple views include Kruchten's "4+1" view model, the Zachman Framework, TOGAF, DoDAF, and RM-ODP. == History == In the 1970s, methods began to appear in software engineering for modeling with multiple views. Douglas T. Ross and K.E. Schoman in 1977 introduce the constructs context, viewpoint, and vantage point to organize the modeling process in systems requirements definition. According to Ross and Schoman, a viewpoint "makes clear what aspects are considered relevant to achieving ... the overall purpose [of the model]" and determines How do we look at [a subject being modelled]? As examples of viewpoints, the paper offers: Technical, Operational and Economic viewpoints. In 1992, Anthony Finkelstein and others published a very important paper on viewpoints. In that work: "A viewpoint can be thought of as a combination of the idea of an “actor”, “knowledge source”, “role” or “agent” in the development process and the idea of a “view” or “perspective” which an actor maintains." An important idea in this paper was to distinguish "a representation style, the scheme and notation by which the viewpoint expresses what it can see" and "a specification, the statements expressed in the viewpoint's style describing particular domains". Subsequent work, such as IEEE 1471, preserved this distinction by utilizing two separate terms: viewpoint and view, respectively. Since the early 1990s there have been a number of efforts to codify approaches for describing and analyzing system architectures. These are often termed architecture frameworks or sometimes viewpoint sets. Many of these have been funded by the United States Department of Defense, but some have sprung from international or national efforts in ISO or the IEEE. Among these, the IEEE Recommended Practice for Architectural Description of Software-Intensive Systems (IEEE Std 1471-2000) established useful definitions of view, viewpoint, stakeholder and concern and guidelines for documenting a system architecture through the use of multiple views by applying viewpoints to address stakeholder concerns. The advantage of multiple views is that hidden requirements and stakeholder disagreements can be discovered more readily. However, studies show that in practice, the added complexity of reconciling multiple views can undermine this advantage. IEEE 1471 (now ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description) prescribes the contents of architecture descriptions and describes their creation and use under a number of scenarios, including precedented and unprecedented design, evolutionary design, and capture of design of existing systems. In all of these scenarios the overall process is the same: identify stakeholders, elicit concerns, identify a set of viewpoints to be used, and then apply these viewpoint specifications to develop the set of views relevant to the system of interest. Rather than define a particular set of viewpoints, the standard provides uniform mechanisms and requirements for architects and organizations to define their own viewpoints. In 1996 the ISO Reference Model for Open Distributed Processing (RM-ODP) was published to provide a useful framework for describing the architecture and design of large-scale distributed systems. == View model topics == === View === A view of a system is a representation of the system from the perspective of a viewpoint. This viewpoint on a system involves a perspective focusing on specific concerns regarding the system, which suppresses details to provide a simplified model having only those elements related to the concerns of the viewpoint. For example, a security viewpoint focuses on security concerns and a security viewpoint model contains those elements that are related to security from a more general model of a system. A view allows a user to examine a portion of a particular interest area. For example, an Information View may present all functions, organizations, technology, etc. that use a particular piece of information, while the Organizational View may present all functions, technology, and information of concern to a particular organization. In the Zachman Framework views comprise a group of work products whose development requires a particular analytical and technical expertise because they focus on either the “what,” “how,” “who,” “where,” “when,” or “why” of the enterprise. For example, Functional View work products answer the question “how is the mission carried out?” They are most easily developed by experts in functional decomposition using process and activity modeling. They show the enterprise from the point of view of functions. They also may show organizational and information components, but only as they relate to functions. === Viewpoints === In systems engineering, a viewpoint is a partitioning or restriction of concerns in a system. Adoption of a viewpoint is usable so that issues in those aspects can be addressed separately. A good selection of viewpoints also partitions the design of the system into specific areas of expertise. Viewpoints provide the conventions, rules, and languages for constructing, presenting and analysing views. In ISO/IEC 42010:2007 (IEEE-Std-1471-2000) a viewpoint is a specification for an individual view. A view is a representation of a whole system from the perspective of a viewpoint. A view may consist of one or more architectural models. Each such architectural model is developed using the methods established by its associated architectural system, as well as for the system as a whole. === Modeling perspectives === Modeling perspectives is a set of different ways to represent pre-selected aspects of a system. Each perspective has a different focus, conceptualization, dedication and visualization of what the model is representing. In information systems, the traditional way to divide modeling perspectives is to distinguish the structural, functional and behavioral/processual perspectives. This together with rule, object, communication and actor and role perspectives is one way of classifying modeling approaches === Viewpoint model === In any given viewpoint, it is possible to make a model of the system that contains only the objects that are visible from that viewpoint, but also captures all of the objects, relationships and constraints that are present in the system and relevant to that viewpoint. Such a model is said to be a viewpoint model, or a view of the

    Read more →
  • Tabletopia

    Tabletopia

    Tabletopia is an online portal for users to play and create virtual tabletop games. The platform is developed by Tabletopia Inc and initially was released as a web browser based service after a successful crowdfunding campaign in August 2015. In December 2016 Tabletopia was released on Steam, and later in 2018 became available in AppStore and Google Play. == Gameplay == Tabletopia is a sandbox system for running any game. That means no AI or rules enforcement. Participating players will have to know how to play the game. Nevertheless, the platform has some automated actions available, like card-shuffling and dealing, dice-rolling, magnetic placement of components in special zones, hand management, and some others. Tabletopia also features ready game setups for various player numbers to facilitate gameplay. It also has customisable camera controls which let players save camera positions and switch between them using hot keys. People can use the Game Designer mode to design and create their own board games using the component library. They can then monetise the games with a 70/30 split to the game designer. == Development == Tabletopia was created in early 2014, by Tim Bokarev and his partners Artem Zinoviev and Dmitry Sergeev. These co-founders already had experience in the video and board games industry. Their other projects include Promo Interactive, an internet advertising agency, Playtox, a mobile MMORPG, Igrology, a game studio, and Tesera.ru, the main Russian-speaking board gaming portal. By Spring 2014, Artem, Dmitry and Tim created Tabletopia Inc. USA and started development. Tabletopia is a multinational crew that includes professionals from USA, Ukraine, Australia, Ireland, and Germany. The Kickstarter campaign in August 2015 earned $133,721 by 2,545 backers. Tabletopia received Green Light on Steam in September 2015 and was released on Steam in March 2016. The platform remained in Early Access until December 2016, when it was officially released on Steam and on the web. In February 2018 it was released as a stand-alone app for iOS tablets, and in September 2018 for Android tablets.

    Read more →
  • Opponent process

    Opponent process

    The opponent process is a hypothesis of color vision that states that the human visual system interprets information about color by processing signals from the three types of photoreceptor cells in an antagonistic manner. The three types of cones are called L, M, and S. The names stand for "Long wavelength sensitive,” "middle wavelength sensitive," and "short wavelength sensitive." The opponent-process theory implicates three opponent channels: L versus M, S versus (L+M), and a luminance channel (+ versus -). These cone-opponent mechanisms were at one time thought to be the neural substrate for a psychological theory called Hering's Opponent Colors Theory, which calls for three psychologically important opponent color processes: red versus green, blue versus yellow, and black versus white (luminance). The Opponent Colors Theory is named for the German physiologist Ewald Hering who proposed the idea in the late 19th century. However, it has been argued that Hering’s Opponent Colors Theory lacks adequate phenomenological and empirical support, and may not be a necessary feature of normal human color experience. Correspondingly, considerable physiological and behavioral evidence proves that the physiological cone opponent mechanisms do not constitute the neurobiological basis for Hering's Opponent Colors Theory. == Color theory == === Complementary colors === When staring at a bright color for a while (e.g. red), then looking away at a white field, an afterimage is perceived, such that the original color will evoke its complementary color (cyan, in the case of red input). When complementary colors are combined or mixed, they "cancel each other out" and become neutral (white or gray). That is, complementary colors are never perceived as a mixture; there is no "greenish red" or "yellowish blue", despite claims to the contrary. The strongest color contrast that a color can have is its complementary color. Complementary colors may also be called "opposite colors" and they were originally considered the primary evidence in support of Hering's Opponent Colors Theory. There are two fatal problems with this evidence. First, the complement of red is not green, as called for by Hering's theory; it is bluish-green. And second, there exists a complementary color for every color, so there is nothing special about the set of complementary pairs picked out by Hering's theory. === Unique hues === The colors that define the extremes for each opponent channel are called unique hues, as opposed to composite (mixed) hues. Ewald Hering first defined the unique hues as red, green, blue, and yellow, and based them on the concept that these colors could not be simultaneously perceived. For example, a color cannot appear both red and green. These definitions have been experimentally refined and are represented today by average hue angles of 353° (carmine red), 128° (cobalt green), 228° (cobalt blue), 58° (yellow). The unique hues are a defining feature of many psychological color spaces, but there is substantial evidence showing that the unique hues are not hard wired in the nervous system, contrary to the stipulations of Hering's Opponent Colors Theory. Unique hues can differ between individuals and are often used in psychophysical research to measure variations in color perception due to color-vision deficiencies or color adaptation. While there is considerable inter-subject variability when defining unique hues experimentally, an individual's unique hues are very consistent, to within a few nanometers of wavelength. == Physiological basis == === Relation to LMS color space === The trichromatic theory is in conflict with Hering's Opponent Colors Theory, although it is compatible with a physiological opponent process that compares the outputs of the different classes of cone types. The poles of these cone opponent mechanisms do not correspond to the unique hues of Hering's Opponent Colors Theory and unlike the unique hues, have no privilege in color perception. Most humans have three different cone cells in their retinas that facilitate trichromatic color vision. Colors are determined by the proportional excitation of these three cone types, i.e. their quantum catch. The levels of excitation of each cone type are the parameters that define LMS color space. To calculate the opponent process tristimulus values from the LMS color space, the cone excitations must be compared: The luminous (achromatic) opponent channel is a weighted sum of all three cone cells (plus the rod cells in some conditions). The red–green opponent channel is equal to the difference of the L- and M-cones. The blue–yellow opponent channel is equal to the difference of the S-cone and the average/weighted sum of the L- and M-cones. Most mammals have no L cone (the primate L cone arose from a gene duplication of the M cone opsin gene). These mammals still show two kinds of opponent channels in their retinal ganglion cells: the achromatic channel and the blue-yellow opponency channel. === Cone opponent mechanisms are encoded in the retina === The output of different types of cones are compared by cells in the retina including retina bipolar cells (which compare signals from L and M cones) and bistratified retinal ganglion cells (which compare S cone signals with L and M cone signals). The output of bipolar cells is relayed to the visual cortex by the retinal ganglion cells (RGCs) by way of a thalamic relay station called the lateral geniculate nucleus (LGN) of the thalamus. Much of the scientific knowledge of retinal ganglion cell physiology was obtained by neural recordings of cells in the LGN. The cone-opponent mechanisms in the retina and LGN represent a fundamental physiological opponent process but do not represent the unique hues (or Hering's Opponent Colors Theory). For example, the colors that best elicit responses of the bistratified S-(L+M)-opponent neurons are best described as purplish (or lavender) and lime-green, not "blue" and "yellow". The neurons are sometimes referred to as "blue–yellow" neurons, but this is a historical artifact dating to the time when it was thought that Hering's Opponent Colors Theory was hardwired by the retina and the mismatch between the colors to which they are optimally tuned and Hering's Opponent Colors was overlooked. Cone opponent mechanisms exist in the retinas of many mammals, including monkeys, mice, and cats. In primates, the LGN contains three major classes of layers: Magnocellular layers (M, large-cell) – responsible largely for the luminance channel Parvocellular layers (P, small-cell) – responsible largely for red–green opponency Koniocellular layers (K) – responsible largely for blue–yellow opponency, poor spatial resolution, long latency Other mammals such as cats also have three cell types denoted as X (magno), Y (parvo), and W (konio). The W type is beyond most doubt homologous to the primate K type. There are some subtle differences between the M and X types as well as the Y and P types to make the correspondence unclear. === Advantage === Transmitting information in opponent-channel color space could be advantageous over transmitting it in LMS color space ("raw" signals from each cone type). There is some overlap in the wavelengths of light to which the three types of cones (L for long-wave, M for medium-wave, and S for short-wave light) respond, so it is more efficient for the visual system (from a perspective of dynamic range) to record differences between the responses of cones, rather than each type of cone's individual response. Hurvich and Jameson argued that the use of opponent-channel color space would increase color contrast, making the information easier to process by later stages of vision. === Color blindness === Color blindness can be classified by the cone cell that is affected (protan, deutan, tritan) or by the opponent channel that is affected (red–green or blue–yellow). In either case, the channel can either be inactive (in the case of dichromacy) or have a lower dynamic range (in the case of anomalous trichromacy). For example, individuals with deuteranopia see little difference between the red and green unique hues. == History == Johann Wolfgang von Goethe first studied the physiological effect of opposed colors in his Theory of Colours in 1810. Goethe arranged his color wheel symmetrically "for the colours diametrically opposed to each other in this diagram are those which reciprocally evoke each other in the eye. Thus, yellow demands purple; orange, blue; red, green; and vice versa: Thus again all intermediate gradations reciprocally evoke each other." Ewald Hering proposed opponent color theory in 1892. He thought that the colors red, yellow, green, and blue are special in that any other color can be described as a mix of them, and that they exist in opposite pairs. That is, either red or green is perceived and never greenish-red: Even though yellow is a mixture of red and green in the RGB color theory, humans

    Read more →
  • List of JavaScript libraries

    List of JavaScript libraries

    This is a list of notable JavaScript libraries. == Constraint programming == Cassowary (software) CHR.js == DOM (manipulation) oriented == Google Polymer Dojo Toolkit jQuery MooTools Prototype JavaScript Framework == Graphical/visualization (canvas, SVG, or WebGL related) == AnyChart Apache ECharts Babylon.js Chart.js Cytoscape D3.js Dojo Toolkit FusionCharts Google Charts JointJS p5.js Plotly.js Processing.js Raphaël RGraph SWFObject Teechart Three.js Velocity.js Verge3D Webix == GUI (Graphical user interface) and widget related == Angular (application platform) by Google AngularJS by Google Bootstrap Dojo Widgets Ext JS by Sencha Foundation by ZURB jQuery UI jQWidgets OpenUI5 by SAP Polymer (library) by Google qooxdoo React.js by Meta/Facebook Vue.js Webix WinJS Svelte === No longer actively developed === Glow Lively Kernel Script.aculo.us YUI Library == Pure JavaScript/Ajax == Google Closure Library JsPHP Microsoft's Ajax library MochiKit PDF.js Socket.IO Spry framework Underscore.js == Template systems == jQuery Mobile Mustache Jinja-JS Twig.js == Unit testing == Jasmine Mocha QUnit == Test automation == Playwright Cypress == Web-application related (MVC, MVVM) == Angular (application platform) by Google AngularJS by Google Backbone.js Echo Ember.js Enyo Express.js Ext JS Google Web Toolkit JsRender/JsViews Knockout Meteor Mojito MooTools Next.js Nuxt.js OpenUI5 by SAP Polymer (library) by Google Prototype JavaScript Framework qooxdoo React.js SproutCore svelte Vue.js == Other == Blockly Cannon.js MathJax Modernizr TensorFlow Brain.js

    Read more →
  • Deep image compositing

    Deep image compositing

    Deep image compositing is a way of compositing and rendering digital images that emerged in the mid-2010s. In addition to the usual color and opacity channels a notion of spatial depth is created. This allows multiple samples in the depth of the image to make up the final resulting color. This technique produces high quality results and removes artifacts around edges that could not be dealt with otherwise. == Deep data == Deep data is encoded by advanced 3D renderers into an image that samples information about the path each rendered pixel takes along the z axis extending outward from the virtual camera through space, including the color and opacity of every non-opaque surface or volume it passes through along the way, as well as neighboring samples. It might be considered somewhat analogous to the way ray tracing generates simulated photon paths through such mediums; however, ray tracing and other traditional rendering techniques generally produce images that contain only three or four channels of color and opacity values per pixel, flattened into a two dimensional frame. Depth maps, on the other hand, contain z axis information encoded in a grayscale image. Each level of gray represents a different slice of the z space. The "thickness" of each slice is determined at time of render, allowing for more or less depth fidelity depending on how deep the scene is. Depth maps have been a boon to compositors for blending 3D renders with live action and practical elements. To be useful, the map must have high enough bit depth to encode separation between close-to-camera objects and objects near infinity. Most 3D software packages are now capable of generating 16-bit and 32-bit depth maps, providing up to 2 billion depth levels. Depth maps do not however include transparency information about non-opaque surfaces or volumes and as such, objects beyond and viewed through these semi- or fully-transparent objects will have no depth information of their own and may not get composited or blurred correctly. Even the popular addition of cryptomattes to many post-production and VFX studios' pipelines, while providing separate color-coded ID shapes for individual elements in a rendered scene to further bridge the gap between CGI and compositing, don't allow for the nearly automated and fully non-linear workflows that deep data does. This is because deep images encapsulate enough 3D information that normally time-intensive tasks such as rotoscoping with numerous holdout mattes for complex interactions between moving characters and semi-transparent environmental volumes like smoke or water, are essentially trivial. Instead of going through that process, multiple mattes could easily be generated from a single set of deep images with no need to re-render every matte element and background for each case. In addition to that efficiency and flexibility, deep data images inherently provide much higher visual quality in common areas that have been difficult with traditional renders, such as the motion-blurred edges of characters with semi-transparent elements like hair. One downside to the use of deep images is their substantial file size, since they encode a relatively enormous amount of data per frame compared to even multichannel formats such as OpenEXR. === Function-based (integrated) === The data is stored as a function of depth. This results in a function curve that can be used to look up the data at any arbitrary depth. Manipulating the data is harder. === Sample-based (deintegrated) === Each sample is considered as an independent piece and can so be manipulated easily. To make sure the data is representing the right detail, an additional expand value needs to be introduced. == Generating deep data == 3D renderers produce the necessary data as a part of the rendering pipeline. Samples are gathered in depth and then combined. The deep data can be written out before this happens and so is nothing new to the process. Generating deep data from camera data needs a proper depth map. This is used in a couple of cases but still not accurate enough for detailed representation. For basic holdout task this can be sufficient though. == Compositing deep data images == Deep images can be composited like regular images. The depth component makes it easier to determine the layering order. Traditionally this had to be input by the user. Deep images have that information for themselves and need no user input. Edge artifacts are reduced as transparent pixels have more data to work with. == History == Deep Images have been around in 3D rendering packages for quite a while now. The use of them for holdouts was first done at several VFX houses in shaders. Holdout mattes can be generated at render time. Using them in a more interactive manner was started recently by several companies, SideFX integrated it in their Houdini software and facilities like Industrial Light & Magic, DreamWorks Animation, Weta, AnimalLogic and DRD studios have implemented interactive solutions. In 2014 the Academy of Motion Picture Arts and Sciences honored the technology with its annual SciTech awards. Dr. Peter Hillman for the long-term development and continued advancement of innovative, robust and complete toolsets for deep compositing and to Colin Doncaster, Johannes Saam, Areito Echevarria, Janne Kontkanen and Chris Cooper for the development, prototyping and promotion of technologies and workflows for deep compositing. == Resources == Pixar Paper Deep Image Paper Video tutorial of Deep Imaging as used on 2012 film Rise of the Planet of the Apes, Nuke compositing software Deep Compositing Course Deep Image File Format at Google Code Academy Award for the Technology Theory of Deep Pixels OpenEXR Deep Pixels

    Read more →
  • Microsoft Forms

    Microsoft Forms

    Microsoft Forms (formerly Office 365 Forms) is an online survey creator, part of Microsoft 365. == Usage == Forms allows users to create surveys and quizzes with automatic marking. The data can be exported to Microsoft Excel, Power BI dashboards and viewed live using the Present feature. == Phishing and fraud == Due to a wave of phishing attacks utilizing Microsoft 365 in early 2021, Microsoft uses algorithms to automatically detect and block phishing attempts with Microsoft Forms. Also, Microsoft advises Forms users not to submit personal information, such as passwords, in a form or survey. It also place a similar advisory underneath the “Submit” button in every form created with Forms, warning users not to give out their password.

    Read more →
  • Decision list

    Decision list

    Decision lists are a representation for Boolean functions which can be easily learned from examples. Single term decision lists are more expressive than disjunctions and conjunctions; however, 1-term decision lists are less expressive than the general disjunctive normal form and the conjunctive normal form. The language specified by a k-length decision list includes as a subset the language specified by a k-depth decision tree. Learning decision lists can be used for attribute efficient learning, a type of machine learning. == Definition == A decision list (DL) of length r is of the form: if f1 then output b1 else if f2 then output b2 ... else if fr then output br where fi is the ith formula and bi is the ith boolean for i ∈ { 1... r } {\displaystyle i\in \{1...r\}} . The last if-then-else is the default case, which means formula fr is always equal to true. A k-DL is a decision list where all of formulas have at most k terms. Sometimes "decision list" is used to refer to a 1-DL, where all of the formulas are either a variable or its negation.

    Read more →
  • Toad (software)

    Toad (software)

    Toad is a database management toolset from Quest Software for managing relational and non-relational databases using SQL aimed at database developers, database administrators, and data analysts. The Toad toolset runs against Oracle, SQL Server, IBM DB2 (LUW & z/OS), SAP and MySQL. A Toad product for data preparation supports many data platforms. == History == A practicing Oracle DBA, Jim McDaniel, designed Toad for his own use in the mid-1990s. He called it Tool for Oracle Application Developers, shortened to "TOAD". McDaniel initially distributed the tool as shareware and later online as freeware. Quest Software acquired TOAD in October 1998. Quest Software itself was acquired by Dell in 2012 to form Dell Software. In June 2016, Dell announced the sale of their software division, including the Quest business, to Francisco Partners and Elliott Management Corporation. On October 31, 2016, the sale was finalized. On November 1, 2016, the sale of Dell Software to Francisco Partners and Elliott Management was completed, and the company re-launched as Quest Software. == Features == Connection Manager - Allow users to connect natively to the vendor’s database whether on-premise or DBaaS. Browser - Allow users to browse all the different database/schema objects and their properties effective management. Editor - A way to create and maintain scripts and database code with debugging and integration with source control. Unit Testing (Oracle) - Ensures code is functionally tested before it is released into production. Static code review (Oracle) - Ensures code meets required quality level using a rules-based system. SQL Optimization - Provides developers with a way to tune and optimize SQL statements and database code without relying on a DBA. Advanced optimization enables DBAs to tune SQL effectively in production. Scalability testing and database workload replay - Ensures that database code and SQL will scale properly before it gets released into production. == Books == Toad Pocket Reference for Oracle plsql 1st Edition by Jim McDaniel and Patrick McGrath, O'Reilly, 2002 (ISBN 0596003374, ISBN 978-0-596-00337-1) Toad Pocket Reference for Oracle 2nd Edition by Jeff Smith, Bert Scalzo, and Patrick McGrath, O'Reilly, 2005 (ISBN 0596009712, ISBN 978-0-596-00971-7) TOAD Handbook by Bert Scalzo and Dan Hotka, Sams, 2003 (ISBN 0672324865, ISBN 978-0-672-32486-4) TOAD Handbook 2nd Edition by Bert Scalzo and Dan Hotka, Addison-Wesley Professional, 2009 (ISBN 0321649109, ISBN 978-0-321-64910-2). TOAD Handbook 2nd Edition by Bert Scalzo and Dan Hotka, Addison-Wesley Professional, 2009 (ISBN 0321649109, ISBN 978-0-321-64910-2).

    Read more →
  • Google Cloud Dataflow

    Google Cloud Dataflow

    Google Cloud Dataflow is a fully managed service for executing Apache Beam pipelines within the Google Cloud Platform ecosystem. Dataflow provides a fully managed service for executing Apache Beam pipelines, offering features like autoscaling, dynamic work rebalancing, and a managed execution environment. Dataflow is suitable for large-scale, continuous data processing jobs, and is one of the major components of Google's big data architecture on the Google Cloud Platform. At its core, Dataflow's architecture is designed to abstract away infrastructure management, allowing developers to focus purely on the logic of their data processing tasks. When a pipeline written using the Apache Beam SDK is submitted, Dataflow translates this high-level definition into an optimized job graph. The service then provisions and manages a fleet of Google Compute Engine workers to execute this graph in a highly parallelized and fault-tolerant manner. This serverless approach, combined with intelligent autoscaling of both the number of workers (horizontal) and the resources per worker (vertical), ensures that jobs have the precise amount of computational power needed at any given time, optimizing both performance and cost. The service's deep integration with the Google Cloud ecosystem makes it a powerful tool for a variety of use cases beyond simple data movement. For real-time analytics, Dataflow can ingest unbounded streams of data from Cloud Pub/Sub, perform complex transformations, and load results into BigQuery for immediate querying. In machine learning workflows, it is commonly used to preprocess and transform massive datasets stored in Cloud Storage, preparing them for training models in Vertex AI. This versatility makes it the central processing engine for modern ETL (Extract, Transform, Load) operations, streaming analytics, and large-scale data preparation within the cloud. == History == Google Cloud Dataflow was announced in June, 2014 and released to the general public as an open beta in April, 2015. In January, 2016 Google donated the underlying SDK, the implementation of a local runner, and a set of IOs (data connectors) to access Google Cloud Platform data services to the Apache Software Foundation. The donated code formed the original basis for Apache Beam. In August 2022, there was an incident where user timers were broken for certain Dataflow streaming pipelines in multiple regions, which was later resolved. Throughout 2023 and 2024, there have been various other updates and incidents affecting Google Cloud Dataflow, as documented in the release notes and service health history. The donation of the Dataflow SDK to the Apache Software Foundation was a pivotal moment, establishing Apache Beam as a unified, open-source programming model for defining both batch and streaming data pipelines. This strategic move decoupled the pipeline definition from the execution engine. As a result, developers could write portable data processing logic that was not locked into Google's ecosystem. A Beam pipeline can be executed on various runners, including Apache Flink, Apache Spark, and, of course, the highly optimized Google Cloud Dataflow service, providing flexibility and future-proofing data processing investments. == Features == Google Cloud Dataflow supports both batch and streaming data processing pipelines. It automatically handles resource provisioning, data sharding, and scaling according to workload, reducing manual configuration needed for large-scale data operations. == Use cases == Dataflow is used for ETL (Extract, Transform, Load) data pipelines, real-time analytics, and event stream processing for companies in industries such as finance, advertising, and IoT.

    Read more →