AI Content Platform

AI Content Platform — independent reviews, comparisons, pricing and step-by-step guides on Aizhi.

Mobile DevOps

Mobile DevOps is a set of practices that applies the principles of DevOps specifically to the development of mobile applications. Traditional DevOps focuses on streamlining the software development process in general, but mobile development has its own unique challenges that require a tailored approach. Mobile DevOps is not simply as a branch of DevOps specific to mobile app development, instead an extension and reinterpretation of the DevOps philosophy due to very specific requirements of the mobile world. == Rationale == Traditional DevOps approach has been formed around 2007-2008, close to the dates when iOS and Android mobile operating systems were released to the public. The traditional DevOps approach primarily evolved to meet the changing needs of the software development world with the paradigm shift towards continuous and rapid development and deployment (such as in web development, where interpreted languages are more prevalent than compiled languages). While traditional DevOps embraced agility and flexibility, mobile operating system providers steered towards a walled-garden approach with compiled apps with tight controls over how they can be distributed and installed on a mobile device. This difference in the mobile development mindset compared to what the traditional DevOps approach is advocating, is augmented further with the mobile applications to be deployed on a high number of varying devices and operating systems. Eventually, the concept of Mobile DevOps took off as a trend around 2014-2015, in line with the fast growth of the number of applications in mobile app stores. As individuals and corporations alike are developing and publishing more and more mobile applications, the need for efficiency and shorter release cycles increased, which is addressed by the continuous feedback and continuous development approach within the concept of DevOps, while requiring a significant level of adaptation and extension of the traditional DevOps practices. == Mindset shift from traditional DevOps to mobile DevOps == Mobile DevOps has a unique set of challenges and constraints, which solidifies the fact that it needs to be approached as a separate discipline. These challenges can be outlined as follows: Platform-specific requirements and tight controls of mobile operating system providers, where for instance a macOS device is mandatory for iOS application development and release. The walled-garden approach of distributing mobile apps, specifically applying to iOS applications, which comes with app review and app release delays that would not be needed in web development, for instance. Code signing requirements that come with the walled-garden approach, which introduce additional processes in the mobile application build pipeline along with new security concerns. An entire deployment cycle is re-run even in the slightest code change due to how applications are compiled and delivered to the users. The final product is to be deployed to a wide variety of mobile devices worldwide, which requires extensive testing and user feedback. Monitoring mobile applications require additional tools and approaches to be able to get data from an application running on a mobile device while respecting user privacy. Frequent operating system updates by mobile platforms can require rapid adaptation of apps, introducing further complexity to the development and maintenance cycles. == Benefits of mobile DevOps == Mobile DevOps is not an abstract concept and offers a range of benefits that can help improve the efficiency and effectiveness of the mobile app development process. These benefits can even be quantified by collecting the data within the mobile application development lifecycle. The benefits can be categorized into the following areas: Faster Release Cycles: By automating tasks and streamlining the development process, mobile DevOps enables teams to deliver new features and updates more frequently. Improved Quality: Automated testing and continuous monitoring help to identify and fix bugs earlier in the development cycle, leading to higher quality apps. Optimized Resource Utilization: Mobile DevOps promotes optimized resource utilization by automating tasks and streamlining workflows. Furthermore, mobile DevOps practices like containerization can help to create more efficient and scalable development environments. Increased Agility: Mobile DevOps allows teams to be more responsive to changes in the market and user feedback. == List of Dedicated Mobile DevOps Platforms == Even though it is possible to run a mobile DevOps cycle with most of the CI/CD platforms, they may require significant effort compared to non-mobile CI/CD (e.g. you need to bring your own infrastructure or it may require "reinventing the wheel" for commonly used platforms like Jenkins). To overcome the mobile-specific challenges specified, there are certain platforms that are dedicated to the lifecycle of mobile applications. These platforms exclusively focus on DevOps processes for mobile app development and are also referred as mobile CI/CD platforms. Appcircle (Multiplatform | Cloud-based & On-premise) Visual Studio App Center (Multiplatform | Cloud-based) Xcode Cloud (Apple platforms only | Cloud-based)
Read more →
Termcap

Termcap (terminal capability) is a legacy software library and database used on Unix-like computers that enables programs to use display computer terminals in a terminal-independent manner, which greatly simplifies the process of writing portable text mode applications. It was superseded by the terminfo database used by ncurses, tput, and other programs. A termcap database can describe the capabilities of hundreds of different display terminals. This allows programs to have character-based display output, independent of the type of terminal. On-screen text editors such as vi and Emacs are examples of programs that may use termcap. Other programs are listed in the Termcap category. Access to the termcap database was usually provided by separate libraries, e.g. GNU Termcap. Examples of what the database describes: how many columns wide the display is what string to send to move the cursor to an arbitrary position (including how to encode the row and column numbers) how to scroll the screen up one or several lines how much padding is needed for such a scrolling operation. == History == Bill Joy wrote the first termcap library in 1978 for the Berkeley Unix operating system; it has since been ported to most Unix and Unix-like environments, even OS-9. Joy's design was reportedly influenced by the design of the terminal data store in the earlier Incompatible Timesharing System. == Data model == Termcap databases consist of one or more descriptions of terminals. === Indices === Each description must contain the canonical name of the terminal. It may also contain one or more aliases for the name of the terminal. The canonical name or aliases are the keys by which the library searches the termcap database. === Data values === The description contains one or more capabilities, which have conventional names. The capabilities are typed: boolean, numeric and string. The termcap library has no predetermined type for each capability name. It determines the types of each capability by the syntax: string capabilities have an "=" between the capability name and its value, numeric capabilities have a "#" between the capability name and its value, and boolean capabilities have no associated value (they are always true if specified). Applications which use termcap do expect specific types for the commonly used capabilities, and obtain the values of capabilities from the termcap database using library calls that return successfully only when the database contents matches the assumed type. === Hierarchy === Termcap descriptions can be constructed by including the contents of one description in another, suppressing capabilities from the included description or overriding or adding capabilities. No matter what storage model is used, the termcap library constructs the terminal description from the requested description, including, suppressing or overriding at the time of the request. == Storage model == Termcap data is stored as text, making it simple to modify. The text can be retrieved by the termcap library from files or environment variables. === Environment variables === The TERM environment variable contains the terminal type name. The TERMCAP environment variable may contain a termcap database. It is most often used to store a single termcap description, set by a terminal emulator to provide the terminal's characteristics to the shell and dependent programs. The TERMPATH environment variable is supported by newer termcap implementations and defines a search path for termcap files. === Flat file === The original (and most common) implementation of the termcap library retrieves data from a flat text file. Searching a large termcap file, e.g., 500 kB, can be slow. To aid performance, a utility such as reorder is used to put the most frequently used entries near the beginning of the file. === Hashed database === 4.4BSD based implementations of termcap store the terminal description in a hashed database (e.g., something like Berkeley DB version 1.85). These store two types of records: aliases which point to the canonical entry, and the canonical entry itself. The text of the termcap entry is stored literally. == Limitations and extensions == The original termcap implementation was designed to use little memory: the first name is two characters, to fit in 16 bits capability names are two characters descriptions are limited to 1023 characters. only one termcap entry with its definitions can be included, and must be at the end. Newer implementations of the termcap interface generally do not require the two-character name at the beginning of the entry. Capability names are still two characters in all implementations. The tgetent function used to read the terminal description uses a buffer whose size must be large enough for the data, and is assumed to be 1024 characters. Newer implementations of the termcap interface may relax this constraint by allowing a null pointer in place of the fixed buffer, or by hiding the data which would not fit, e.g., via the ZZ capability in NetBSD termcap. The terminfo library interface also emulates the termcap interface, and does not actually use the fixed-size buffer. The terminfo library's emulation of termcap allows multiple other entries to be included without restricting the position. A few other newer implementations of the termcap library may also provide this ability, though it is not well documented. == Obsolete features == A special capability, the "hz" capability, was defined specifically to support the Hazeltine 1500 terminal, which had the unfortunate characteristic of using the ASCII tilde character ('~') as a control sequence introducer. In order to support that terminal, not only did code that used the database have to know about using the tilde to introduce certain control sequences, but it also had to know to substitute another printable character for any tildes in the displayed text, since a tilde in the text would be interpreted by the terminal as the start of a control sequence, resulting in missing text and screen garbling. Additionally, attribute markers (such as start and end of underlining) themselves took up space on the screen. Comments in the database source code often referred to this as "Hazeltine braindamage". Since the Hazeltine 1500 was a widely used terminal in the late 1970s, it was important for applications to be able to deal with its limitations.
Read more →
Adrozek

Adrozek is malware that injects fake ads into online search results. Microsoft announced the malware threat on 10 December 2020, and noted that many different browsers are affected, including Google Chrome, Microsoft Edge, Mozilla Firefox and Yandex Browser. The malware was first detected in May 2020 and, at its peak in August 2020, controlled over 30,000 devices a day. But during the December 2020 announcement, Microsoft claimed "hundreds of thousands" of infected devices worldwide between May and September 2020. According to Microsoft, if not detected and blocked, Adrozek adds browser extensions, modifies a specific DLL per target browser, and changes browser settings to insert additional, unauthorized ads into web pages, often on top of legitimate ads from search engines. For each user tricked into clicking on the fake ads, the scammers earn affiliate advertising dollars. The malware has been observed to extract device data and, in some cases, steal credentials, sending them to remote servers. Users may unintentionally install the malware because of a drive-by download, by visiting a tampered website, opening an e-mail attachment, or clicking on a deceptive link or a deceptive pop-up window. The main malware program is downloaded to the “Programs Files” folder using file names such as Audiolava.exe, QuickAudio.exe, and converter.exe. According to PC Magazine, a good way to avoid, or mitigate, infection by Adrozek is to keep browser and related software programs up to date.
Read more →
Vinted

Vinted Group UAB is a Lithuanian technology company best known for its online marketplace Vinted. Vinted is the leading second-hand fashion marketplace in Europe and a go-to destination for all kinds of second-hand items. According to the company, its mission is to make second-hand the first choice worldwide. The company operates as an ecosystem of businesses, including the Vinted Marketplace (its peer-to-peer resale platform), Vinted Go (logistics and shipping services), Vinted Pay (in-app payment solutions), and Vinted Ventures (an investment arm supporting the circular economy). Headquartered in Vilnius, Lithuania, it also has offices in Germany and the Netherlands and employs more than 2,200 people. == History == Vinted was co-founded in 2008 by Milda Mitkute and Justas Janauskas in Vilnius, Lithuania. The idea originated when Mitkute was moving house and wanted a way to sell clothes she no longer needed. Janauskas helped her create a website where users could trade clothing items. In 2016, Dutch entrepreneur Thomas Plantenga joined Vinted as a strategy consultant and later became Chief Executive Officer, leading the company through a period of international growth. In 2019, Vinted became Lithuania’s first technology unicorn after raising €128 million at a €1 billion valuation in a funding round led by Lightspeed Venture Partners. In October 2020, it acquired United Wardrobe, a Dutch competitor, and in November 2020 German Kleiderkreisel and Mamikreisel were officially merged into the Vinted platform. In 2024 it acquired Trendsales, a Danish resale platform. According to Vogue Business, Vinted’s revenue grew 61% between 2022 and 2023 and the company posted a net profit of €17.8 million in 2023. Usage of Vinted in the UK has grown from 1.2 million users in 2021, to 8 million in 2023. In 2024, the group reported consolidated revenue of €813.4 million (up 36% from 2023) and a net profit of €76.7 million, up 330% from 2023. As of 2024, Vinted was valued at approximately €5 billion, operating in more than 26 markets worldwide and announcing plans to launch in Ireland, Greece, Latvia, Slovenia, and Estonia in 2025. As of 2025 the company employed more than 2,200 people. In April 2026, Vinted completed a secondary share transaction of €880m, valuing the company at €8bn. == Products and operations == Vinted primarily resells clothing but now supports multiple categories including homeware, kidswear, electronics, books, collectibles, and high-value fashion. Vinted has worked with public figures such as Paul Mescal and Alexa Chung on exclusive wardrobe sales and has also partnered directly with charities including Oxfam on initiatives which promote the social and environmental value of second-hand fashion, such as the Style for Change fashion show at London Fashion Week. In 2025, Vinted produced its first television format, the second-hand fashion competition series RE/Style, hosted by Emma Willis. The show features emerging fashion designers from across Europe creating runway-ready looks from second-hand garments and aired on Prime Video UK. In 2025, Vinted was reported as France’s top clothing retailer by sales volume. == Criticism == Vinted has faced scrutiny from European data protection authorities in France, Lithuania, and Poland following complaints regarding GDPR compliance and account blocking practices. In July 2024, the Lithuanian authority fined the company €2,375,276. The case was coordinated by a dedicated Vinted Working Group under the European Data Protection Board. In early 2024, Swedish police reported around 300 fraud cases linked to the platform, in which users’ bank accounts were targeted by scammers. In October 2024, Channel 4 in the United Kingdom aired a documentary examining safety and privacy concerns related to the platform, including the sexualisation of underage users’ images and risks associated with second-hand baby products lacking safety certification. In November 2025, BBC News reported that Vinted’s update to its sizing system in the United Kingdom led to widespread user criticism. Vinted said the update was intended to standardise sizing across international brands.
Read more →
Yap (company)

Yap Speech Cloud was a multimodal speech recognition system developed by American technology company Yap Inc. It offered a fully cloud-based speech-to-text transcription platform that was used by customers such as Microsoft. The Company was a contestant at the inaugural TechCrunch conference and was subsequently acquired by Amazon in September 2011 to help develop products such as Alexa Voice Service, Echo, and Fire TV.
Read more →
WebGPU Shading Language

WebGPU Shading Language (WGSL, internet media type: text/wgsl) is a high-level shading language and the normative shader language for the WebGPU API on the web. WGSL's syntax is influenced by Rust and is designed with strong static validation, explicit resource binding, and portability in mind for secure execution in browsers. In web contexts, WebGPU implementations accept WGSL source and perform compilation to platform-specific intermediate forms (for example, to SPIR‑V, DXIL, or MSL via the user agent), but such backends are not exposed to web content. == History and background == Graphics on the web historically used WebGL, with shaders written in GLSL ES. As applications demanded more modern GPU features and finer control over compute and graphics pipelines, the W3C's GPU for the Web Community Group and Working Group created WebGPU and its companion shading language, WGSL, to provide a secure, portable model suitable for the web platform. WGSL was developed to be human-readable, avoid undefined behavior common in legacy shading languages, and align closely with WebGPU's resource and validation model. == Design goals == WGSL's design emphasizes: Safety and determinism suitable for web security constraints (extensive static validation and well-defined semantics). Portability across diverse GPU backends via an abstract resource model shared with WebGPU. Readability and explicitness (no preprocessor, minimal implicit conversions, explicit address spaces and bindings). Alignment with modern GPU features (compute, storage buffers, textures, atomics) while retaining a familiar C/Rust-like syntax. == Language overview == === Types and values === Core scalar types include bool, i32, u32, and f32. Vectors (e.g., vec2, vec3, vec4) and matrices (up to 4×4) are available for floating-point element types. Optional f16 (half precision) may be enabled via a WebGPU feature; availability is implementation-dependent. Atomic types (atomic, atomic) support limited atomic operations in qualified address spaces. === Variables and address spaces === Variables are declared with let (immutable), var (mutable), or const (compile-time constant). Storage classes (address spaces) include function, private, workgroup, uniform, and storage with read or read_write access as applicable. WGSL defines explicit layout and alignment rules; attributes such as @align, @size, and @stride control data layout for buffer interoperability. === Functions and control flow === Functions use explicit parameter and return types. Control flow includes if, switch, for, while, and loop constructs, with break/continue. Recursion is disallowed; entry-point call graphs must be acyclic. === Entry points and attributes === Shaders define stage entry points with @vertex, @fragment, or @compute. Attributes annotate bindings and interfaces, including @group, @binding (resource binding), @location (user-defined I/O), @builtin (stage built-ins such as position or global_invocation_id), @interpolate, and @workgroup_size. === Resources === WGSL exposes buffers (uniform, storage), textures (sampled, storage, and multisampled variants), and samplers (filtering/non-filtering/comparison). The binding model is explicit via descriptor sets called groups and bindings, matching WebGPU's pipeline layout model. == Compilation and validation == Browsers compile WGSL to platform-appropriate representations and native driver formats; the specific compilation pipeline is not observable by web content. WGSL source undergoes strict parsing and static validation, and WebGPU enforces robust resource access rules to avoid out-of-bounds memory hazards, contributing to predictable behavior across implementations. == Shader stages == WGSL supports three pipeline stages: vertex, fragment, and compute. === Vertex shaders === Vertex shaders transform per-vertex inputs and produce values for rasterization, including a clip-space position written to the position builtin. ==== Example ==== === Fragment shaders === Fragment shaders run per-fragment and compute color (and optionally depth) outputs written to color attachments. ==== Example ==== If half-precision (vec4h, shorthand for vec4) is desired, the code must be prefaced with a enable f16; statement. === Compute shaders === Compute shaders run in workgroups and are used for general-purpose GPU computations. ==== Example ==== == Differences from GLSL and HLSL == Compared with legacy shading languages, WGSL: Omits a preprocessor and requires explicit types and conversions. Uses explicit address spaces and binding annotations aligned with WebGPU's model. Enforces strict validation to avoid undefined behavior common in other shading languages. Defines a portable, web-focused feature set; 16-bit types and other features are opt-in and may depend on device capabilities.
Read more →
Gonioreflectometer

A gonioreflectometer is a device for measuring a bidirectional reflectance distribution function (BRDF). The device consists of a light source illuminating the material to be measured and a sensor that captures light reflected from that material. The light source should be able to illuminate and the sensor should be able to capture data from a hemisphere around the target. The hemispherical rotation dimensions of the sensor and light source are the four dimensions of the BRDF. The 'gonio' part of the word refers to the device's ability to measure at different angles. Several similar devices have been built and used to capture data for similar functions. Most of these devices use a camera instead of the light intensity-measuring sensor to capture a two-dimensional sample of the target. Examples include: a spatial gonioreflectometer for capturing the SBRDF (McAllister, 2002). a camera gantry for capturing the light field (Levoy and Hanrahan, 1996). an unnamed device for capturing the bidirectional texture function (Dana et al., 1999).
Read more →
EPUAP

ePUAP (Electronic Platform of Public Administration Services) is a Polish nationwide platform for communication of citizens with public administrations in a uniform and standardized way. Built as part of the ePUAP-WKP project (State Informatization Plan). Service providers are public administration units and public institutions (especially entities that perform tasks commissioned by the state). The platform provides service providers with technological infrastructure to provide services to citizens (recipients). Among the participants of ePUAP there are both central administration units and local governments, including municipal offices. Among the services offered by ePUAP is also Profil Zaufany (Trusted Profile), which enables electronic filing with legal effect without the need to use a qualified signature and SAML-based single sign-on mechanism, which enables the same ePUAP account to log on to websites of various service providers. The website www.epuap.gov.pl enables defining citizen and businesses service processes, creates channels of access to different systems of public administration and extends the package of public services provided electronically. Services available through the ePUAP platform may be accessed at the official website. Currently all administration services are available in Polish only. == Overview == It is described by the Polish government as "a coherent and systematic action program designed and developed to allow public institutions make their electronic services available to the public". The platform provides citizens, businesses and institutions with a number of services intended to ensure smooth and safe communication between: customer to administrations (C2A), business to administration (B2A), administration to administration (A2A). === Main goals === The main project objectives are to create a single, secure and electronic access channel to public services for citizens, businesses and public administration and also to reduce time and lower the costs of sharing information resources and functionalities of administration domain systems. Within the project, the following functionalities and services were delivered: Public services catalogue – a method of presenting and describing administration services, ePUAP platform – a web platform designed to provide public services on the Internet, Interoperability portal – a portal for experts working on recommendations for electronic documents and forms used within Polish administration systems to assure the uniformity of IT standards, Central Repository of Electronic Document Models – a database for valid document models and electronic forms. == History and background == The ePUAP project was carried out in the years 2005–2008. Currently, a continuation project ePUAP2 is being carried out with the following objectives: to increase the number of online services available to the public including the registry services, to widen the scale of usage of public electronic services, to integrate subsequent systems of public administration and business on ePUAP portal, to define new processes of customer and business services. === ePUAP2 === ePUAP2 is a public and administrative project that extends the set of functional services developed during the first edition of the project and is another step in the process of transforming Poland into a modern and citizen-friendly country. The implementation period for the project covers the years 2009–2013. Project financing The cost of the project “Construction of electronic Platform of Public Administration Services” – 32 million PLN was covered in 75% by the funds from the European Regional Development Fund (under the Sector Operational Programme "Supporting Competitiveness of Enterprises for the years 2004–2006"), while the remaining 25% of the cost was covered by a Polish national co-financing. Funds for the ePUAP2 project were gained from the 7th priority axis of the Innovative Economy Operational Programme and amounts to 140 million PLN (85% of eligible expenses were covered by the European Regional Development Fund, 15% were covered by a national co-financing). The trustee of ePUAP is the Polish Ministry of the Interior and Administration. == Legal regulations == According to the Polish law from 1 May 2008, public authorities are required to accept documents in electronic form (bringing applications and proposals and other activities in electronic form). ePUAP enables public institutions to meet this requirement by providing a service infrastructure to set up am electronic inbox. The ePUAP inbox meets legal requirements, in particular: issuing an official confirmation of receipt in accordance with the regulation of the Prime Minister of 29 September 2005 on the organizational and technical conditions for the delivery of electronic documents to public entities; cooperation with hardware security modules (HSM), meeting the technical requirements set out in the law; handling documents electronically in accordance with the minimum requirements set out in the Regulation of the Polish Council of Ministers of 11 October 2005 on minimum requirements for ICT systems. == Incidents == === Crashes === The ePUAP system very often happens smaller or larger failures. Because it is used to sign the application profiles trusted also in other electronic systems such as public administration. Electronic Services Platform created by ZUS, the system fault ePUAP it very difficult to settle official matters most electronically. === "Infoafera" === According to TVN and the release of TVP News from 10 April 2014, the creation of ePUAP is also associated with the so-called "Infoafera." On 10 April 2014, the Minister of Internal Affairs of Poland confirmed the information that the American technology company HP confessed to its participation in the Polish info-tour and corruption of Polish officials. By March 2014, the construction of ePUAP and its maintenance cost PLN 98.4 million. PLN 67.8 million has been used for this project. Challenged expenses only on the portal itself is approx. PLN 20 million.
Read more →
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 →
Elasticity (data store)

The elasticity of a data store relates to the flexibility of its data model and clustering capabilities. The greater the number of data model changes that can be tolerated, and the more easily the clustering can be managed, the more elastic the data store is considered to be. == Types == === Clustering elasticity === Clustering elasticity is the ease of adding or removing nodes from the distributed data store. Usually, this is a difficult and delicate task to be done by an expert in a relational database system. Some NoSQL data stores, like Apache Cassandra have an easy solution, and a node can be added/removed with a few changes in the properties and by adding specifying at least one seed. === Data-modelling elasticity === Relational databases are most often very inelastic, as they have a predefined data model that can only be adapted through redesign. Most NoSQL data stores, however, do not have a fixed schema. Each row can have a different number and even different type of columns. Concerning the data store, modifications in the schema are no problem. This makes this kind of data stores more elastic concerning the data model. The drawback is that the programmer has to take into account that the data model may change over time.
Read more →
Reflection lines

Engineers use reflection lines to judge a surface's quality. Reflection lines reveal surface flaws, particularly discontinuities in normals indicating that the surface is not C 2 {\displaystyle C^{2}} . Reflection lines may be created and examined on physical surfaces or virtual surfaces with the help of computer graphics. For example, the shiny surface of an automobile body is illuminated with reflection lines by surrounding the car with parallel light sources. Virtually, a surface can be rendered with reflection lines by modulating the surfaces point-wise color according to a simple calculation involving the surface normal, viewing direction and a square wave environment map. == Mathematical definition == Consider a point p {\displaystyle p} on a surface M {\displaystyle M} with (normalized) normal n {\displaystyle n} . If an observer views this point from infinity at view direction v {\displaystyle v} then the reflected view direction r {\displaystyle r} is: r = v − 2 ( n ⋅ v ) n . {\displaystyle r=v-2(n\cdot v)n.} (The vector v {\displaystyle v} is decomposed into its normal part v n = ( n ⋅ v ) v {\displaystyle v_{n}=(n\cdot v)v} and tangential part v t = v − v n {\displaystyle v_{t}=v-v_{n}} . Upon reflection, the tangential part is kept and the normal part is negated.) For reflection lines we consider the surface M {\displaystyle M} surrounded by parallel lines with direction a {\displaystyle a} , representing infinite, non-dispersive light sources. For each point p {\displaystyle p} on M {\displaystyle M} we determine which line is seen from direction v {\displaystyle v} . The position on each line is of no interest. Define the vector r p {\displaystyle r_{p}} to be the reflection direction r {\displaystyle r} projected onto a plane P {\displaystyle P} that is orthogonal to a {\displaystyle a} : r p = r − ( r ⋅ a ) a {\displaystyle r_{p}=r-(r\cdot a)a} and similarly let v p {\displaystyle v_{p}} be the viewing direction projected onto P {\displaystyle P} : v p = v − ( v ⋅ a ) a {\displaystyle v_{p}=v-(v\cdot a)a} Finally, define v o {\displaystyle v_{o}} to be the direction lying in P {\displaystyle P} perpendicular to a {\displaystyle a} and v p {\displaystyle v_{p}} : v o = a × v p {\displaystyle v_{o}=a\times v_{p}} Using these vectors, the reflection line function θ ( p ) : M → ( − π , π ] {\displaystyle \theta (p):M\rightarrow (-\pi ,\pi ]} is a scalar function mapping points p {\displaystyle p} on the surface to angles between v p {\displaystyle v_{p}} and r p {\displaystyle r_{p}} : θ = arctan ⁡ ( r p ⋅ v o , r p ⋅ v p ) {\displaystyle \theta =\arctan {(r_{p}\cdot v_{o},r_{p}\cdot v_{p})}} where a r c t a n ( y , x ) {\displaystyle arctan(y,x)} is the atan2 function producing a number in the range ( − π , π ] {\displaystyle (-\pi ,\pi ]} . ( v p {\displaystyle v_{p}} and v o {\displaystyle v_{o}} can be viewed as a local coordinate system in P {\displaystyle P} with x {\displaystyle x} -axis in direction v p {\displaystyle v_{p}} and y {\displaystyle y} -axis in direction v o {\displaystyle v_{o}} .) Finally, to render the reflection lines positive values θ > 0 {\displaystyle \theta >0} are mapped to a light color and non-positive values to a dark color. == Highlight lines == Highlight lines are a view-independent alternative to reflection lines. Here the projected normal is directly compared against some arbitrary vector x {\displaystyle x} perpendicular to the light source: θ = arctan ⁡ ( n a ⋅ a ⊥ , n a ⋅ x ) {\displaystyle \theta =\arctan {(n_{a}\cdot a^{\perp },n_{a}\cdot x)}} where n a {\displaystyle n_{a}} is the surface normal projected on the light source plane P {\displaystyle P} : n a ^ / | n a ^ | , n a ^ = n − ( n ⋅ a ) a {\displaystyle {\hat {n_{a}}}/|{\hat {n_{a}}}|,{\hat {n_{a}}}=n-(n\cdot a)a} The relationship between reflection lines and highlight lines is likened to that between specular and diffuse shading.
Read more →
Data event

A data event is a relevant state transition defined in an event schema. Typically, event schemata are described by pre- and post condition for a single or a set of data items. In contrast to ECA (Event condition action), which considers an event to be a signal, the data event not only refers to the change (signal), but describes specific state transitions, which are referred to in ECA as conditions. Considering data events as relevant data item state transitions allows defining complex event-reaction schemata for a database. Defining data event schemata for relational databases is limited to attribute and instance events. Object-oriented databases also support collection properties, which allows defining changes in collections as data events, too.
Read more →
CEITON

CEITON is a web-based software system for facilitating and automating business processes such as planning, scheduling, and payroll using workflow technologies. The system is used by several media companies such as MDR, Yle, RAI and Red Bull Media House. In December 2018, the first CEITON User Group Meeting took place in Leipzig, Germany. == Architecture == The software runs on a server (on premises) or in the cloud and is scalable on parallel servers. Data security is warranted by role-based access control (RBAC). The software is used via web-browsers and not dependent on particular system software. == Structure and Features == CEITON combines the two classical approaches of production planning and control and workflow management. === Project Management === The scheduling system plans, manages, bills, and analyzes projects or tasks. It manages human and technical resources, material, and locations on a single GUI. The system uses a gantt chart to assign tasks to be done to available and eligible resources (i.e. staff), automatically or by drag-and-drop. The scheduling module includes material management, resource management/ human resource management, integration of freelancers, clients and suppliers, long-term budget planning, time-tracking, shift scheduling, quality management, delivery and logistics, document management, archive, analysis and controlling, business reporting, as well as all accounting and documentation processes. === Workflow === The workflow management system module coordinates business processes. Processes are defined once as a workflow and then repeatedly executed. Human resources are automatically assigned to steps (tasks) and integrated in workflow forms. Systems are integrated with an EAI/SOAP module, allowing data exchange with arbitrary external systems which are also involved in the business process. It also features a 3-D workflow overview in which the status of each project step can be determined by its color in the overview. === Process Management === For project and order processing management, business processes are designed as workflows, and coordinate communication automatically. Different user interfaces for staff, customers or suppliers can be created so each gets only relevant information. Different workflow forms are associated with different log-ins. The main application for the system is knowledge-based business processes, in which many people are involved and virtual results are produced, e.g. in research, or development of media products, such as TV and movies. Broadcasters and media companies such as MDR and Yle use CEITON to control their production processes for products and services and coordinate complex workflows with all kinds of resources. === Integrations === An integrated EAI module allows CEITON to integrate every external system in any business process without programming, using SOAP and similar technologies. Aspera and FileCatalyst were integrated for faster data transfer, yet complex ERP systems and numerous SAP modules have also been integrated, for example, to extract working times to payroll. === Mobile Working === Since Version 7, released in 2015, CEITON includes a time-tracking module allowing employees to enter their times from mobile devices such as tablets running Android, iPhones etc. == History == Ceiton Technologies (SME tech firm), the company developing CEITON, was founded in Leipzig, Germany in 2000, staffing solutions for the Bureau of Internal Revenue in Manila, Philippines, were implemented in 2000 together with the Deutsche Gesellschaft für Technische Zusammenarbeit of the German government. The first version (1.0) of the software was released in July 2001. The product was originally developed for German broadcasting companies. CEITON is named after the Japanese concept Seiton, one of the principles of Japanese workplace design methodology known as 5S. Since version 7, released in 2015, CEITON includes a time-tracking module allowing employees to enter their times from mobile devices such as tablets running Android, iPhones etc. In May 2005 CEITON won the IQ innovation award, sponsored by Siemens, in the category Excellent innovation in the IT-sector. Since 2007, CEITON has been present at the broadcast trade fairs NAB in Las Vegas and IBC in Amsterdam. In 2020, the company celebrated its 20th anniversary.
Read more →
Commitment ordering

Commitment ordering (CO) is a class of interoperable serializability techniques in concurrency control of databases, transaction processing, and related applications. It allows optimistic (non-blocking) implementations. With the proliferation of multi-core processors, CO has also been increasingly utilized in concurrent programming, transactional memory, and software transactional memory (STM) to achieve serializability optimistically. CO is also the name of the resulting transaction schedule (history) property, defined in 1988 with the name dynamic atomicity. In a CO compliant schedule, the chronological order of commitment events of transactions is compatible with the precedence order of the respective transactions. CO is a broad special case of conflict serializability and effective means (reliable, high-performance, distributed, and scalable) to achieve global serializability (modular serializability) across any collection of database systems that possibly use different concurrency control mechanisms (CO also makes each system serializability compliant, if not already). Each not-CO-compliant database system is augmented with a CO component (the commitment order coordinator—COCO) which orders the commitment events for CO compliance, with neither data-access nor any other transaction operation interference. As such, CO provides a low overhead, general solution for global serializability (and distributed serializability), instrumental for global concurrency control (and distributed concurrency control) of multi-database systems and other transactional objects, possibly highly distributed (e.g., within cloud computing, grid computing, and networks of smartphones). An atomic commitment protocol (ACP; of any type) is a fundamental part of the solution, utilized to break global cycles in the conflict (precedence, serializability) graph. CO is the most general property (a necessary condition) that guarantees global serializability, if the database systems involved do not share concurrency control information beyond atomic commitment protocol (unmodified) messages and have no knowledge of whether transactions are global or local (the database systems are autonomous). Thus CO (with its variants) is the only general technique that does not require the typically costly distribution of local concurrency control information (e.g., local precedence relations, locks, timestamps, or tickets). It generalizes the popular strong strict two-phase locking (SS2PL) property, which in conjunction with the two-phase commit protocol (2PC), is the de facto standard to achieve global serializability across (SS2PL based) database systems. As a result, CO compliant database systems (with any different concurrency control types) can transparently join such SS2PL based solutions for global serializability. In addition, locking based global deadlocks are resolved automatically in a CO based multi-database environment, a vital side-benefit (including the special case of a completely SS2PL based environment; a previously unnoticed fact for SS2PL). Furthermore, strict commitment ordering (SCO; Raz 1991c), the intersection of Strictness and CO, provides better performance (shorter average transaction completion time and resulting in better transaction throughput) than SS2PL whenever read-write conflicts are present (identical blocking behavior for write-read and write-write conflicts; comparable locking overhead). The advantage of SCO is especially during lock contention. Strictness allows both SS2PL and SCO to use the same effective database recovery mechanisms. Two major generalizing variants of CO exist, extended CO (ECO; Raz 1993a) and multi-version CO (MVCO; Raz 1993b). They also provide global serializability without local concurrency control information distribution, can be combined with any relevant concurrency control, and allow optimistic (non-blocking) implementations. Both use additional information for relaxing CO constraints and achieving better concurrency and performance. Vote ordering (VO or Generalized CO (GCO); Raz 2009) is a container schedule set (property) and technique for CO and all its variants. Local VO is necessary for guaranteeing global serializability if the atomic commitment protocol (ACP) participants do not share concurrency control information (have the generalized autonomy property). CO and its variants inter-operate transparently, guaranteeing global serializability and automatic global deadlock resolution together in a mixed, heterogeneous environment with different variants. == Overview == The Commitment ordering (CO; Raz 1990, 1992, 1994, 2009) schedule property has been referred to also as Dynamic atomicity (since 1988), commit ordering, commit order serializability, and strong recoverability (since 1991). The latter is a misleading name since CO is incomparable with recoverability, and the term "strong" implies a special case. This means that a substantial recoverability property does not necessarily have the CO property and vice versa. In 2009 CO has been characterized as a major concurrency control method, together with the previously known (since the 1980s) three major methods: Locking, Time-stamp ordering, and Serialization graph testing, and as an enabler for the interoperability of systems using different concurrency control mechanisms. In a federated database system or any other more loosely defined multidatabase system, which are typically distributed in a communication network, transactions span multiple and possibly Distributed databases. Enforcing global serializability in such system is problematic. Even if every local schedule of a single database is still serializable, the global schedule of a whole system is not necessarily serializable. The massive communication exchanges of conflict information needed between databases to reach conflict serializability would lead to unacceptable performance, primarily due to computer and communication latency. The problem of achieving global serializability effectively had been characterized as open until the public disclosure of CO in 1991 by its inventor Yoav Raz (Raz 1991a; see also Global serializability). Enforcing CO is an effective way to enforce conflict serializability globally in a distributed system since enforcing CO locally in each database (or other transactional objects) also enforces it globally. Each database may use any, possibly different, type of concurrency control mechanism. With a local mechanism that already provides conflict serializability, enforcing CO locally does not cause any other aborts, since enforcing CO locally does not affect the data access scheduling strategy of the mechanism (this scheduling determines the serializability related aborts; such a mechanism typically does not consider the commitment events or their order). The CO solution requires no communication overhead since it uses (unmodified) atomic commitment protocol messages only, already needed by each distributed transaction to reach atomicity. An atomic commitment protocol plays a central role in the distributed CO algorithm, which enforces CO globally by breaking global cycles (cycles that span two or more databases) in the global conflict graph. CO, its special cases, and its generalizations are interoperable and achieve global serializability while transparently being utilized together in a single heterogeneous distributed environment comprising objects with possibly different concurrency control mechanisms. As such, Commitment ordering, including its special cases, and together with its generalizations (see CO variants below), provides a general, high performance, fully distributed solution (no central processing component or central data structure are needed) for guaranteeing global serializability in heterogeneous environments of multidatabase systems and other multiple transactional objects (objects with states accessed and modified only by transactions; e.g., in the framework of transactional processes, and within Cloud computing and Grid computing). The CO solution scales up with network size and the number of databases without any negative impact on performance (assuming the statistics of a single distributed transaction, e.g., the average number of databases involved with a single transaction, are unchanged). With the proliferation of Multi-core processors, Optimistic CO (OCO) has also been increasingly utilized to achieve serializability in software transactional memory, and numerous STM articles and patents utilizing "commit order" have already been published (e.g., Zhang et al. 2006). == The commitment ordering solution for global serializability == === General characterization of CO === Commitment ordering (CO) is a special case of conflict serializability. CO can be enforced with non-blocking mechanisms (each transaction can complete its task without having its data-access blocked, which allows optimistic concurrency control; however, commitment could be blo
Read more →
My Drama

My Drama (also may be stylised as MyDrama) is a global streaming service specializing in vertical video series for Duanju. It is owned by the company Holywater Tech. The platform focuses on short-form, emotional storytelling optimized for smartphone viewing, offering content in over 30 languages across 190 countries. == History == My Drama was launched in 2024 by Holywater Tech, founded by Ukrainian entrepreneur Bogdan Nesvit and Anatolii Kasianov. The service gained international traction as part of a growing market for short-form vertical storytelling, influenced by mobile-first entertainment trends. My Drama primarily streams serialized vertical dramas, which are short-form episodes around 1-2 minutes in length designed for mobile consumption. Many series are adaptations of successful stories originally published on Holywater Tech's book platform My Passion. The platform employs AI technology in areas such as content recommendation and story generation, and is one of several Holywater apps focused on interactive entertainment. In 2024, My Drama won a People's Voice award at the 28th Annual Webby Awards. In 2025, My Drama received a Gold Award at the MUSE Creative Awards in the Mobile App: Video Streaming Services category. In 2025, the company received strategic investment from Fox Entertainment, aimed at expanding content creation capabilities and producing over 200 vertical video series. As of 2025, My Drama has produced over 56 titles and reached more than 40 million lifetime users, according to media reports. In January 2026, Holywater Tech raised $22 million in funding to expand its microdrama business in the United States. The investment round was led by Horizon Capital, with participation from U.S.-based investors including Endeavor Catalyst and Wheelhouse. The funding is intended to support the development of Holywater Tech's mobile-first vertical video platform, My Drama, as well as the company's AI-driven content initiatives, such as AI-assisted comics and anime. In February 2026, Holywater bought Jeynix, a studio that uses AI for special effects. This deal helps the company make better-quality shows and translate them into different languages much faster. == Partnerships == In 2024, Holywater Tech entered a partnership with Latin American studio Elefantec Global to distribute vertical dramas in Spanish-language markets. In early 2026, Fox Entertainment entered into a partnership with content creator Dhar Mann to produce a slate of 40 original vertical microdrama series. Under the agreement, the series debut exclusively on the My Drama platform, while global distribution is managed by Fox Entertainment Global. == Reception == My Drama has been highlighted in discussions of the global rise of vertical short drama platforms and has been compared with similar apps such as ReelShort and DramaBox.
Read more →