AI Chatbot Questionnaire

AI Chatbot Questionnaire — independent reviews, comparisons, pricing and step-by-step guides on Aizhi.

Neurorobotics

Neurorobotics is the combined study of neuroscience, robotics, and artificial intelligence. It is the science and technology of embodied autonomous neural systems. Neural systems include brain-inspired algorithms (e.g. connectionist networks), computational models of biological neural networks (e.g. artificial spiking neural networks, large-scale simulations of neural microcircuits) and actual biological systems (e.g. in vivo and in vitro neural nets). Such neural systems can be embodied in machines with mechanic or any other forms of physical actuation. This includes robots, prosthetic or wearable systems but also, at smaller scale, micro-machines and, at the larger scales, furniture and infrastructures. Neurorobotics is that branch of neuroscience with robotics, which deals with the study and application of science and technology of embodied autonomous neural systems like brain-inspired algorithms. It is based on the idea that the brain is embodied and the body is embedded in the environment. Therefore, most neurorobots are required to function in the real world, as opposed to a simulated environment. Beyond brain-inspired algorithms for robots neurorobotics may also involve the design of brain-controlled robot systems. == Major classes of models == Neurorobots can be divided into various major classes based on the robot's purpose. Each class is designed to implement a specific mechanism of interest for study. Common types of neurorobots are those used to study motor control, memory, action selection, and perception. === Locomotion and motor control === Neurorobots are often used to study motor feedback and control systems, and have proved their merit in developing controllers for robots. Locomotion is modeled by a number of neurologically inspired theories on the action of motor systems. Locomotion control has been mimicked using models or central pattern generators, clumps of neurons capable of driving repetitive behavior, to make four-legged walking robots. Other groups have expanded the idea of combining rudimentary control systems into a hierarchical set of simple autonomous systems. These systems can formulate complex movements from a combination of these rudimentary subsets. This theory of motor action is based on the organization of cortical columns, which progressively integrate from simple sensory input into a complex afferent signals, or from complex motor programs to simple controls for each muscle fiber in efferent signals, forming a similar hierarchical structure. Another method for motor control uses learned error correction and predictive controls to form a sort of simulated muscle memory. In this model, awkward, random, and error-prone movements are corrected for using error feedback to produce smooth and accurate movements over time. The controller learns to create the correct control signal by predicting the error. Using these ideas, robots have been designed which can learn to produce adaptive arm movements or to avoid obstacles in a course. === Learning and memory systems === Robots designed to test theories of animal memory systems. Many studies examine the memory system of rats, particularly the rat hippocampus, dealing with place cells, which fire for a specific location that has been learned. Systems modeled after the rat hippocampus are generally able to learn mental maps of the environment, including recognizing landmarks and associating behaviors with them, allowing them to predict the upcoming obstacles and landmarks. Another study has produced a robot based on the proposed learning paradigm of barn owls for orientation and localization based on primarily auditory, but also visual stimuli. The hypothesized method involves synaptic plasticity and neuromodulation, a mostly chemical effect in which reward neurotransmitters such as dopamine or serotonin affect the firing sensitivity of a neuron to be sharper. The robot used in the study adequately matched the behavior of barn owls. Furthermore, the close interaction between motor output and auditory feedback proved to be vital in the learning process, supporting active sensing theories that are involved in many of the learning models. Neurorobots in these studies are presented with simple mazes or patterns to learn. Some of the problems presented to the neurorobot include recognition of symbols, colors, or other patterns and execute simple actions based on the pattern. In the case of the barn owl simulation, the robot had to determine its location and direction to navigate in its environment. === Action selection and value systems === Action selection studies deal with negative or positive weighting to an action and its outcome. Neurorobots can and have been used to study simple ethical interactions, such as the classical thought experiment where there are more people than a life raft can hold, and someone must leave the boat to save the rest. However, more neurorobots used in the study of action selection contend with much simpler persuasions such as self-preservation or perpetuation of the population of robots in the study. These neurorobots are modeled after the neuromodulation of synapses to encourage circuits with positive results. In biological systems, neurotransmitters such as dopamine or acetylcholine positively reinforce neural signals that are beneficial. One study of such interaction involved the robot Darwin VII, which used visual, auditory, and a simulated taste input to "eat" conductive metal blocks. The arbitrarily chosen good blocks had a striped pattern on them while the bad blocks had a circular shape on them. The taste sense was simulated by conductivity of the blocks. The robot had positive and negative feedbacks to the taste based on its level of conductivity. The researchers observed the robot to see how it learned its action selection behaviors based on the inputs it had. Other studies have used herds of small robots which feed on batteries strewn about the room, and communicate its findings to other robots. === Sensory perception === Neurorobots have also been used to study sensory perception, particularly vision. These are primarily systems that result from embedding neural models of sensory pathways in automatas. This approach gives exposure to the sensory signals that occur during behavior and also enables a more realistic assessment of the degree of robustness of the neural model. It is well known that changes in the sensory signals produced by motor activity provide useful perceptual cues that are used extensively by organisms. For example, researchers have used the depth information that emerges during replication of human head and eye movements to establish robust representations of the visual scene. == Biological robots == Biological robots are not officially neurorobots in that they are not neurologically inspired AI systems, but actual neuron tissue wired to a robot. This employs the use of cultured neural networks to study brain development or neural interactions. These typically consist of a neural culture raised on a multielectrode array (MEA), which is capable of both recording the neural activity and stimulating the tissue. In some cases, the MEA is connected to a computer which presents a simulated environment to the brain tissue and translates brain activity into actions in the simulation, as well as providing sensory feedback The ability to record neural activity gives researchers a window into a brain, which they can use to learn about a number of the same issues neurorobots are used for. An area of concern with the biological robots is ethics. Many questions are raised about how to treat such experiments. The central question concerns consciousness and whether or not the rat brain experiences it. There are many theories about how to define consciousness. == Implications for neuroscience == Neuroscientists benefit from neurorobotics because it provides a blank slate to test various possible methods of brain function in a controlled and testable environment. While robots are more simplified versions of the systems they emulate, they are more specific, allowing more direct testing of the issue at hand. They also have the benefit of being accessible at all times, while it is more difficult to monitor large portions of a brain while the human or animal is active, especially individual neurons. The development of neuroscience has produced neural treatments. These include pharmaceuticals and neural rehabilitation. Progress is dependent on an intricate understanding of the brain and how exactly it functions. It is difficult to study the brain, especially in humans, due to the danger associated with cranial surgeries. Neurorobots can improved the range of tests and experiments that can be performed in the study of neural processes.
Read more →
Round-trip engineering

Round-trip engineering (RTE) in the context of model-driven architecture is a functionality of software development tools that synchronizes two or more related software artifacts, such as, source code, models, configuration files, documentation, etc. between each other. The need for round-trip engineering arises when the same information is present in multiple artifacts and when an inconsistency may arise in case some artifacts are updated. For example, some piece of information was added to/changed in only one artifact (source code) and, as a result, it became missing in/inconsistent with the other artifacts (in models). == Overview == Round-trip engineering is closely related to traditional software engineering disciplines: forward engineering (creating software from specifications), reverse engineering (creating specifications from existing software), and reengineering (understanding existing software and modifying it). Round-trip engineering is often wrongly defined as simply supporting both forward and reverse engineering. In fact, the key characteristic of round-trip engineering that distinguishes it from forward and reverse engineering is the ability to synchronize existing artifacts that evolved concurrently by incrementally updating each artifact to reflect changes made to the other artifacts. Furthermore, forward engineering can be seen as a special instance of RTE in which only the specification is present and reverse engineering can be seen as a special instance of RTE in which only the software is present. Many reengineering activities can also be understood as RTE when the software is updated to reflect changes made to the previously reverse engineered specification. === Types === Various books describe two types of RTE: partial or uni-directional RTE: changes made to a higher level representation of a code and model are reflected in lower level, but not otherwise; the latter might be allowed, but with limitations that may not affect higher-level abstractions full or bi-directional RTE: regardless of changes, both higher and lower-level code and model representations are synchronized if any of them altered === Auto synchronization === Another characteristic of round-trip engineering is automatic update of the artifacts in response to automatically detected inconsistencies. In that sense, it is different from forward- and reverse engineering which can be both manual (traditionally) and automatic (via automatic generation or analysis of the artifacts). The automatic update can be either instantaneous or on-demand. In instantaneous RTE, all related artifacts are immediately updated after each change made to one of them. In on-demand RTE, authors of the artifacts may concurrently update the artifacts (even in a distributed setting) and at some point choose to execute matching to identify inconsistencies and choose to propagate some of them and reconcile potential conflicts. === Iterative approach === Round trip engineering may involve an iterative development process. After you have synchronized your model with revised code, you are still free to choose the best way to work – make further modifications to the code or make changes to your model. You can synchronize in either direction at any time and you can repeat the cycle as many times as necessary. == Software == Many commercial tools and research prototypes support this form of RTE; a 2007 book lists Rational Rose, Together, ESS-Model, BlueJ, and Fujaba among those capable, with Fujaba said to be capable to also identify design patterns. == Limitations == A 2005 book on Visual Studio notes for instance that a common problem in RTE tools is that the model reversed is not the same as the original one, unless the tools are aided by leaving laborious annotations in the source code. The behavioral parts of UML impose even more challenges for RTE. Usually, UML class diagrams are supported to some degree; however, certain UML concepts, such as associations and containment do not have straightforward representations in many programming languages which limits the usability of the created code and accuracy of code analysis/reverse engineering (e.g., containment is hard to recognize in the code). A more tractable form of round-trip engineering is implemented in the context of framework application programming interfaces (APIs), whereby a model describing the usage of a framework API by an application is synchronized with that application's code. In this setting, the API prescribes all correct ways the framework can be used in applications, which allows precise and complete detection of API usages in the code as well as creation of useful code implementing correct API usages. Two prominent RTE implementations in this category are framework-specific modeling languages and Spring Roo (Java). Round-trip engineering is critical for maintaining consistency among multiple models and between the models and the code in Object Management Group's (OMG) Model-driven architecture. OMG proposed the QVT (query/view/transformation) standard to handle model transformations required for MDA. To date, a few implementations of the standard have been created. (Need to present practical experiences with MDA in relation to RTE). == Controversies == === Code generation controversy === Code generation (forward-engineering) from models means that the user abstractly models solutions, which are connoted by some model data, and then an automated tool derives from the models parts or all of the source code for the software system. In some tools, the user can provide a skeleton of the program source code, in the form of a source code template where predefined tokens are then replaced with program source code parts during the code generation process. UML (if used for MDA) diagrams specification was criticized for lack the detail which is needed to contain the same information as is covered with the program source. Some developers even claim that "the Code is the design". == Disadvantages == There is a serious risk that the generated code will rapidly differ from the model or that the reverse-engineered model will lose its reflection on the code or a mix of these two problems as result of cycled reengineering efforts. Regarding behavioral/dynamic part of UML for features like statechart diagram there is no equivalents in programming languages. Their translation during code-generation will result in common programming statement (.e.g if,switch,enum) being either missing or misinterpreted. If edited and imported back may result in different or incomplete model. The same goes for code snippets used for code generation stage for the pattern-implementation and user-specific logic: intermixed they may not be easily reverse-engineered back. There is also general lack of advanced tooling for modelling that are comparable to that of modern IDEs (for testing, debugging, navigation, etc.) for general-purpose programming languages and domain-specific languages. == Examples in software engineering == Perhaps the most common form of round-trip engineering is synchronization between UML (Unified Modeling Language) models and the corresponding source code and entity–relationship diagrams in data modelling and database modelling. Round-trip engineering based on Unified Modeling Language (UML) needs three basic tools for software development: Source Code Editor; UML Editor for the Attributes and Methods; Visualisation of UML structure
Read more →
Digital image correlation and tracking

Digital image correlation and tracking is an optical method that employs tracking and image registration techniques for accurate 2D and 3D measurements of changes in 2D images or 3D volumes. This method is often used to measure full-field displacement and strains, and it is widely applied in many areas of science and engineering. Compared to strain gauges and extensometers, digital image correlation methods provide finer details about deformation, due to the ability to provide both local and average data. == Overview == Digital image correlation (DIC) techniques have been increasing in popularity, especially in micro- and nano-scale mechanical testing applications due to their relative ease of implementation and use. Advances in computer technology and digital cameras have been the enabling technologies for this method and while white-light optics has been the predominant approach, DIC can be and has been extended to almost any imaging technology. The concept of using cross-correlation to measure shifts in datasets has been known for a long time, and it has been applied to digital images since at least the early 1970s. The present-day applications are almost innumerable, including image analysis, image compression, velocimetry, and strain estimation. Much early work in DIC in the field of mechanics was led by researchers at the University of South Carolina in the early 1980s and has been optimized and improved in recent years. Commonly, DIC relies on finding the maximum of the correlation array between pixel intensity array subsets on two or more corresponding images, which gives the integer translational shift between them. It is also possible to estimate shifts to a finer resolution than the resolution of the original images, which is often called "sub-pixel" registration because the measured shift is smaller than an integer pixel unit. For sub-pixel interpolation of the shift, other methods do not simply maximize the correlation coefficient. An iterative approach can also be used to maximize the interpolated correlation coefficient by using non-linear optimization techniques. The non-linear optimization approach tends to be conceptually simpler and can handle large deformations more accurately, but as with most nonlinear optimization techniques, it is slower. The two-dimensional discrete cross correlation r i j {\displaystyle r_{ij}} can be defined in several ways, one possibility being: r i j = ∑ m ∑ n [ f ( m + i , n + j ) − f ¯ ] [ g ( m , n ) − g ¯ ] ∑ m ∑ n [ f ( m , n ) − f ¯ ] 2 ∑ m ∑ n [ g ( m , n ) − g ¯ ] 2 . {\displaystyle r_{ij}={\frac {\sum _{m}\sum _{n}[f(m+i,n+j)-{\bar {f}}][g(m,n)-{\bar {g}}]}{\sqrt {\sum _{m}\sum _{n}{[f(m,n)-{\bar {f}}]^{2}}\sum _{m}\sum _{n}{[g(m,n)-{\bar {g}}]^{2}}}}}.} Here f(m, n) is the pixel intensity or the gray-scale value at a point (m, n) in the original image, g(m, n) is the gray-scale value at a point (m, n) in the translated image, f ¯ {\displaystyle {\bar {f}}} and g ¯ {\displaystyle {\bar {g}}} are mean values of the intensity matrices f and g respectively. However, in practical applications, the correlation array is usually computed using Fourier-transform methods, since the fast Fourier transform is a much faster method than directly computing the correlation. F = F { f } , G = F { g } . {\displaystyle \mathbf {F} ={\mathcal {F}}\{f\},\quad \mathbf {G} ={\mathcal {F}}\{g\}.} Then taking the complex conjugate of the second result and multiplying the Fourier transforms together elementwise, we obtain the Fourier transform of the correlogram, R {\displaystyle \ R} : R = F ∘ G ∗ , {\displaystyle R=\mathbf {F} \circ \mathbf {G} ^{},} where ∘ {\displaystyle \circ } is the Hadamard product (entry-wise product). It is also fairly common to normalize the magnitudes to unity at this point, which results in a variation called phase correlation. Then the cross-correlation is obtained by applying the inverse Fourier transform: r = F − 1 { R } . {\displaystyle \ r={\mathcal {F}}^{-1}\{R\}.} At this point, the coordinates of the maximum of r i j {\displaystyle r_{ij}} give the integer shift: ( Δ x , Δ y ) = arg ⁡ max ( i , j ) { r } . {\displaystyle (\Delta x,\Delta y)=\arg \max _{(i,j)}\{r\}.} == Deformation mapping == For deformation mapping, the mapping function that relates the images can be derived from comparing a set of subwindow pairs over the whole images. (Figure 1). The coordinates or grid points (xi, yj) and (xi, yj) are related by the translations that occur between the two images. If the deformation is small and perpendicular to the optical axis of the camera, then the relation between (xi, yj) and (xi, yj) can be approximated by a 2D affine transformation such as: x ∗ = x + u + ∂ u ∂ x Δ x + ∂ u ∂ y Δ y , {\displaystyle x^{}=x+u+{\frac {\partial u}{\partial x}}\Delta x+{\frac {\partial u}{\partial y}}\Delta y,} y ∗ = y + v + ∂ v ∂ x Δ x + ∂ v ∂ y Δ y . {\displaystyle y^{}=y+v+{\frac {\partial v}{\partial x}}\Delta x+{\frac {\partial v}{\partial y}}\Delta y.} Here u and v are translations of the center of the sub-image in the X and Y directions respectively. The distances from the center of the sub-image to the point (x, y) are denoted by Δ x {\displaystyle \Delta x} and Δ y {\displaystyle \Delta y} . Thus, the correlation coefficient rij is a function of displacement components (u, v) and displacement gradients ∂ u ∂ x , ∂ u ∂ y , ∂ v ∂ x , ∂ v ∂ y . {\displaystyle {\frac {\partial u}{\partial x}},{\frac {\partial u}{\partial y}},{\frac {\partial v}{\partial x}},{\frac {\partial v}{\partial y}}.} DIC has proven to be very effective at mapping deformation in macroscopic mechanical testing, where the application of specular markers (e.g. paint, toner powder) or surface finishes from machining and polishing provide the needed contrast to correlate images well. However, these methods for applying surface contrast do not extend to the application of free-standing thin films for several reasons. First, vapor deposition at normal temperatures on semiconductor grade substrates results in mirror-finish quality films with RMS roughnesses that are typically on the order of several nanometers. No subsequent polishing or finishing steps are required, and unless electron imaging techniques are employed that can resolve microstructural features, the films do not possess enough useful surface contrast to adequately correlate images. Typically this challenge can be circumvented by applying paint that results in a random speckle pattern on the surface, although the large and turbulent forces resulting from either spraying or applying paint to the surface of a free-standing thin film are too high and would break the specimens. In addition, the sizes of individual paint particles are on the order of μms, while the film thickness is only several hundred nanometers, which would be analogous to supporting a large boulder on a thin sheet of paper. == Digital volume correlation == Digital Volume Correlation (DVC, and sometimes called Volumetric-DIC) extends the 2D-DIC algorithms into three dimensions to calculate the full-field 3D deformation from a pair of 3D images. This technique is distinct from 3D-DIC, which only calculates the 3D deformation of an exterior surface using conventional optical images. The DVC algorithm is able to track full-field displacement information in the form of voxels instead of pixels. The theory is similar to above except that another dimension is added: the z-dimension. The displacement is calculated from the correlation of 3D subsets of the reference and deformed volumetric images, which is analogous to the correlation of 2D subsets described above. DVC can be performed using volumetric image datasets. These images can be obtained using confocal microscopy, X-ray computed tomography, Magnetic Resonance Imaging or other techniques. Similar to the other DIC techniques, the images must exhibit a distinct, high-contrast 3D "speckle pattern" to ensure accurate displacement measurement. DVC was first developed in 1999 to study the deformation of trabecular bone using X-ray computed tomography images. Since then, applications of DVC have grown to include granular materials, metals, foams, composites and biological materials. To date it has been used with images acquired by MRI imaging, Computer Tomography (CT), micro-CT, confocal microscopy, and lightsheet microscopy. DVC is currently considered to be ideal in the research world for 3D quantification of local displacements, strains, and stress in biological specimens. It is preferred because of the non-invasiveness of the method over traditional experimental methods. Two of the key challenges are improving the speed and reliability of the DVC measurement. The 3D imaging techniques produce noisier images than conventional 2D optical images, which reduces the quality of the displacement measurement. Computational speed is restricted by the file sizes of 3D images, which are significantly larger than 2D images. For example, an
Read more →
Apache Kudu

Apache Kudu is a free and open source column-oriented data store of the Apache Hadoop ecosystem. It is compatible with most of the data processing frameworks in the Hadoop environment. It provides completeness to Hadoop's storage layer to enable fast analytics on fast data. The open source project to build Apache Kudu began as internal project at Cloudera. The first version Apache Kudu 1.0 was released 19 September 2016. == Comparison with other storage engines == Kudu was designed and optimized for OLAP workloads. Like HBase, it is a real-time store that supports key-indexed record lookup and mutation. Kudu differs from HBase since Kudu's datamodel is a more traditional relational model, while HBase is schemaless. Kudu's "on-disk representation is truly columnar and follows an entirely different storage design than HBase/Bigtable".
Read more →
Multisample anti-aliasing

Multisample anti-aliasing (MSAA) is a type of spatial anti-aliasing, a technique used in computer graphics to remove jaggies. It is an optimization of supersampling, where only the necessary parts are sampled more. Jaggies are only noticed in a small area, so the area is quickly found, and only that is anti-aliased. == Definition == The term generally refers to a special case of supersampling. Initial implementations of full-scene anti-aliasing (FSAA) worked conceptually by simply rendering a scene at a higher resolution, and then downsampling to a lower-resolution output. Most modern GPUs are capable of this form of anti-aliasing, but it greatly taxes resources such as texture, bandwidth, and fillrate. (If a program is highly TCL-bound or CPU-bound, supersampling can be used without much performance hit.) According to the OpenGL GL_ARB_multisample specification, "multisampling" refers to a specific optimization of supersampling. The specification dictates that the renderer evaluate the fragment program once per pixel, and only "truly" supersample the depth and stencil values. (This is not the same as supersampling but, by the OpenGL 1.5 specification, the definition had been updated to include fully supersampling implementations as well.) In graphics literature in general, "multisampling" refers to any special case of supersampling where some components of the final image are not fully supersampled. The lists below refer specifically to the ARB_multisample definition. == Description == In supersample anti-aliasing, multiple locations are sampled within every pixel, and each of those samples is fully rendered and combined with the others to produce the pixel that is ultimately displayed. This is computationally expensive, because the entire rendering process must be repeated for each sample location. It is also inefficient, as aliasing is typically only noticed in some parts of the image, such as the edges, whereas supersampling is performed for every single pixel. In multisample anti-aliasing, if any of the multi sample locations in a pixel is covered by the triangle being rendered, a shading computation must be performed for that triangle. However this calculation only needs to be performed once for the whole pixel regardless of how many sample positions are covered; the result of the shading calculation is simply applied to all of the relevant multi sample locations. In the case where only one triangle covers every multi sample location within the pixel, only one shading computation is performed, and these pixels are little more expensive than (and the result is no different from) the non-anti-aliased image. This is true of the middle of triangles, where aliasing is not an issue. (Edge detection can reduce this further by explicitly limiting the MSAA calculation to pixels whose samples involve multiple triangles, or triangles at multiple depths.) In the extreme case where each of the multi sample locations is covered by a different triangle, a different shading computation will be performed for each location and the results then combined to give the final pixel, and the result and computational expense are the same as in the equivalent supersampled image. The shading calculation is not the only operation that must be performed on a given pixel; multisampling implementations may variously sample other operations such as visibility at different sampling levels. == Advantages == The pixel shader usually only needs to be evaluated once per pixel for every triangle covering at least one sample point. The edges of polygons (the most obvious source of aliasing in 3D graphics) are anti-aliased. Since multiple subpixels per pixel are sampled, polygonal details smaller than one pixel that might have been missed without MSAA can be captured and made a part of the final rendered image if enough samples are taken. == Disadvantages == === Alpha testing === Alpha testing is a technique common to older video games used to render translucent objects by rejecting pixels from being written to the framebuffer. If the alpha value of a translucent fragment (pixel) is below a specified threshold, it will be discarded. Because this is performed on a pixel by pixel basis, the image does not receive the benefits of multi-sampling (all of the multisamples in a pixel are discarded based on the alpha test) for these pixels. The resulting image may contain aliasing along the edges of transparent objects or edges within textures, although the image quality will be no worse than it would be without any anti-aliasing. Translucent objects that are modelled using alpha-test textures will also be aliased due to alpha testing. This effect can be minimized by rendering objects with transparent textures multiple times, although this would result in a high performance reduction for scenes containing many transparent objects. === Aliasing === Because multi-sampling calculates interior polygon fragments only once per pixel, aliasing and other artifacts will still be visible inside rendered polygons where fragment shader output contains high frequency components. === Performance === While less performance-intensive than SSAA (supersampling), it is possible in certain scenarios (scenes heavy in complex fragments) for MSAA to be multiple times more intensive for a given frame than post processing anti-aliasing techniques such as FXAA, SMAA and MLAA. Early techniques in this category tend towards a lower performance impact, but suffer from accuracy problems. More recent post-processing based anti-aliasing techniques such as temporal anti-aliasing (TAA), which reduces aliasing by combining data from previously rendered frames, have seen the reversal of this trend, as post-processing AA becomes both more versatile and more expensive than MSAA, which cannot antialias an entire frame alone. == Sampling methods == === Point sampling === In a point-sampled mask, the coverage bit for each multisample is only set if the multisample is located inside the rendered primitive. Samples are never taken from outside a rendered primitive, so images produced using point-sampling will be geometrically correct, but filtering quality may be low because the proportion of bits set in the pixel's coverage mask may not be equal to the proportion of the pixel that is actually covered by the fragment in question. === Area sampling === Filtering quality can be improved by using area sampled masks. In this method, the number of bits set in a coverage mask for a pixel should be proportionate to the actual area coverage of the fragment. This will result in some coverage bits being set for multisamples that are not actually located within the rendered primitive, and can cause aliasing and other artifacts. == Sample patterns == === Regular grid === A regular grid sample pattern, where multisample locations form an evenly spaced grid throughout the pixel, is easy to implement and simplifies attribute evaluation (i.e. setting subpixel masks, sampling color and depth). This method is computationally expensive due to the large number of samples. Edge optimization is poor for screen-aligned edges, but image quality is good when the number of multisamples is large. === Sparse regular grid === A sparse regular grid sample pattern is a subset of samples that are chosen from the regular grid sample pattern. As with the regular grid, attribute evaluation is simplified due to regular spacing. The method is less computationally expensive due to having a fewer samples. Edge optimization is good for screen aligned edges, and image quality is good for a moderate number of multisamples. === Stochastic sample patterns === A stochastic sample pattern is a random distribution of multisamples throughout the pixel. The irregular spacing of samples makes attribute evaluation complicated. The method is cost efficient due to low sample count (compared to regular grid patterns). Edge optimization with this method, although sub-optimal for screen aligned edges. Image quality is excellent for a moderate number of samples. == Quality == Compared to supersampling, multisample anti-aliasing can provide similar quality at higher performance, or better quality for the same performance. Further improved results can be achieved by using rotated grid subpixel masks. The additional bandwidth required by multi-sampling is reasonably low if Z and colour compression are available. Most modern GPUs support 2×, 4×, and 8× MSAA samples. Higher values result in better quality, but are slower.
Read more →
Plumbr

Plumbr was an Estonian software product company founded in late 2011 that developed performance monitoring software. The Plumbr product was built on top of a proprietary algorithm that automatically detected the root causes of performance issues by interpreting application performance data. In October 2020, Plumbr was acquired by Splunk. == Products == Plumbr monitored customers' JVM applications for memory leaks, garbage collection pauses and locked threads. Plumbr problem detection algorithms were based on analysis of performance data of thousands of applications. Plumbr consisted of an agent and a portal. Plumbr Agent was attached to application runtime and sent memory usage and garbage collection information to Plumbr Portal. On Plumbr Portal one could see information such as heap and permgen memory usage, garbage collection pauses' and lock contention duration. Clients that were not able to send data to third parties could order a self-hosted portal and have a full solution in-house. In case of performance incidents Plumbr provided its users with information on problem severity and problem's root cause location in source code or runtime configuration, and listed the steps needed to take to remediate the problem. Clients included NASA, NATO, Dell, HBO, Experian, EMC Corporation.
Read more →
Color moments

Color moments are measures that characterise color distribution in an image in the same way that central moments uniquely describe a probability distribution. Color moments are mainly used for color indexing purposes as features in image retrieval applications in order to compare how similar two images are based on color. Usually one image is compared to a database of digital images with pre-computed features in order to find and retrieve a similar Image. Each comparison between images results in a similarity score, and the lower this score is the more identical the two images are supposed to be. == Overview == Color moments are scaling and rotation invariant. It is usually the case that only the first three color moments are used as features in image retrieval applications as most of the color distribution information is contained in the low-order moments. Since color moments encode both shape and color information they are a good feature to use under changing lighting conditions, but they cannot handle occlusion very successfully. Color moments can be computed for any color model. Three color moments are computed per channel (e.g. 9 moments if the color model is RGB and 12 moments if the color model is CMYK). Computing color moments is done in the same way as computing moments of a probability distribution. === Mean === The first color moment can be interpreted as the average color in the image, and it can be calculated by using the following formula E i = ∑ j = 1 N 1 N p i j {\displaystyle E_{i}=\textstyle \sum _{j=1}^{N}{\frac {1}{N}}p_{ij}} where N is the number of pixels in the image and p i j {\displaystyle p_{ij}} is the value of the j-th pixel of the image at the i-th color channel. === Standard Deviation === The second color moment is the standard deviation, which is obtained by taking the square root of the variance of the color distribution. σ i = ( 1 N ∑ j = 1 N ( p i j − E i ) 2 ) {\displaystyle \sigma _{i}={\sqrt {({\frac {1}{N}}\textstyle \sum _{j=1}^{N}(p_{ij}-E_{i})^{2})}}} where E i {\displaystyle E_{i}} is the mean value, or first color moment, for the i-th color channel of the image. === Skewness === The third color moment is the skewness. It measures how asymmetric the color distribution is, and thus it gives information about the shape of the color distribution. Skewness can be computed with the following formula: s i = ( 1 N ∑ j = 1 N ( p i j − E i ) 3 ) 3 σ i {\displaystyle s_{i}={\frac {\sqrt[{3}]{\left({\frac {1}{N}}\textstyle \sum _{j=1}^{N}(p_{ij}-E_{i})^{3}\right)}}{\sigma _{i}}}} === Kurtosis === Kurtosis is the fourth color moment, and, similarly to skewness, it provides information about the shape of the color distribution. More specifically, kurtosis is a measure of how extreme the tails are in comparison to the normal distribution. === Higher-order color moments === Higher-order color moments are usually not part of the color moments feature set in image retrieval tasks as they require more data in order to obtain a good estimate of their value, and also the lower-order moments generally provide enough information. == Applications == Color moments have significant applications in image retrieval. They can be used in order to compare how similar two images are. This is a relatively new approach to color indexing. The greatest advantage of using color moments comes from the fact that there is no need to store the complete color distribution. This greatly speeds up image retrieval since there are less features to compare. In addition, the first three color moments have the same units, which allows for comparison between them. === Color indexing === Color indexing is the main application of color moments. Images can be indexed, and the index will contain the computed color moments. Then, if someone has a particular image and wants to find similar images in the database, the color moments of the image of interest will also be computed. After that the following function will be used in order to compute a similarity score between the image of interest and all the images in the database: d m o m ( H , I ) = ∑ i = 1 r w i 1 | E i 1 − E i 2 | + w i 2 | σ i 1 − σ i 2 | + w i 3 | s i 1 − s i 2 | {\displaystyle d_{mom}(H,I)=\textstyle \sum _{i=1}^{r}w_{i1}|E_{i}^{1}-E_{i}^{2}|+w_{i2}|\sigma _{i}^{1}-\sigma _{i}^{2}|+w_{i3}|s_{i}^{1}-s_{i}^{2}|} where: H and I are the color distributions of the two images that are being compared i is the channel index and r is the total number of channels E i 1 {\displaystyle E_{i}^{1}} and E i 2 {\displaystyle E_{i}^{2}} are the first order moments computed for the image distributions. σ i 1 {\displaystyle \sigma _{i}^{1}} and σ i 2 {\displaystyle \sigma _{i}^{2}} are the second order moments computed for the image distributions. s_i^1 and s_i^2 are the third order moments computed for the image distributions. w i 1 {\displaystyle w_{i1}} , w i 2 {\displaystyle w_{i2}} , and w i 3 {\displaystyle w_{i3}} are weights, specified by the user, for each of the three color moments used. Finally, the images in the database will be ranked according to the computed similarity score with the image of interest, and the database images with the lowest d m o m ( H , I ) {\displaystyle d_{mom}(H,I)} value should be retrieved. "A retrieval based on d m o m ( H , I ) {\displaystyle d_{mom}(H,I)} may produce false positives because the index contains no information about the correlation between the color channels". == Example == A simple and concise example of the use of color moments for image retrieval tasks is illustrated in. Consider having several test images in a database and a "New Image". The goal is to retrieve images from the database that are similar to the "New Image". The first three color moments are used as features. There are several steps in this computation. Image preprocessing (Optional) - The image preprocessing step of the computation process is optional. For example, in this step all images could be modified to be the same size (in terms of pixels). However, since color moments are invariant to scaling, it is not necessary to make all images the same width and height. Computing the features - Use the color moments formulae in order to compute the first three moments for each of the color channels in the image. For example, if the HSV color space is used, this means that for each of the images, 9 features in total will be computed (the first three order moments for the Hue, Saturation, and Value channels). Calculating the similarity score - After computing the color moments the weights for each of the moments in the d m o m ( H , I ) {\displaystyle d_{mom}(H,I)} function should be determined by the user. The weights have to be adjusted each time in accordance with the application or condition and quality of the images. Following that the d m o m ( H , I ) {\displaystyle d_{mom}(H,I)} function is used to calculate a similarity score for the "New Image" and each of the images in the database. Ranking and image retrieval - From the previous step the d m o m ( H , I ) {\displaystyle d_{mom}(H,I)} values were obtained. Now a comparison of these values can be made in order to decide which of the images in the database are more similar to the "New Image", and thus rank the database images accordingly. The smaller the d m o m ( H , I ) {\displaystyle d_{mom}(H,I)} value is the more similar the two color distributions are supposed to be. Finally, some of the top ranked images (the ones with the smallest d m o m ( H , I ) {\displaystyle d_{mom}(H,I)} value) from the database are retrieved.
Read more →
Wunderlist

Wunderlist is a discontinued cloud-based task management application. It allowed users to create lists to manage their tasks from a smartphone, tablet, computer and smartwatch. Wunderlist was free; additional collaboration features were available in a paid version known as Wunderlist Pro, released April 2013. Wunderlist was created in 2011 by Berlin-based startup 6Wunderkinder (Engl.: 6Prodigies). The company was acquired by Microsoft in June 2015, at which time the app had over 13 million users. In April 2017, Microsoft announced that Wunderlist would eventually be discontinued in favor of Microsoft To Do, a new multi-platform app developed by the Wunderlist team that has direct integration with the company's Office 365 service. On December 6, 2019, Microsoft announced that it would shut down Wunderlist on May 6, 2020. After this date, the application would no longer sync but users could still import their content into Microsoft To Do. == History == In 2009, Wunderlist's CEO Christian Reber called on the social network platform XING for business partners to create a new to-do app. Frank Thelen responded and together Reber and Thelen developed first concepts for Wunderlist. The necessary seed funding was granted by High-Tech Gründerfonds and e42 GmbH. The first version of Wunderlist was launched on November 9, 2010. Initially, the program was created for desktop PCs and platforms such as Windows, Linux and Mac OS X. In December 2011, the app received approval for the iPhone. Subsequently, the developers released a version prepared for the iPad with the name Wunderlist HD. In September 2012, the developers announced a shutdown of their service Wunderkit. Instead they wanted to focus on creating a new version of Wunderlist, which was later on released in December 2012 under the name Wunderlist 2. In September 2013, the company announced it had over 5 million users. In July 2014, a new major update was released under the name of Wunderlist 3, with a new real-time sync architecture. Wunderlist reached 10 million users in December 2014. On June 1, 2015, it was announced that Microsoft had acquired 6Wunderkinder, makers of Wunderlist, for between US$100 million and US$200 million (~$258 million in 2024). Following its acquisition of the app, Microsoft announced in April 2017 a preview of To-Do, a multi-platform task management app developed by the Wunderlist team that was intended to eventually replace Wunderlist and incorporate most of its features. As of January 2019, To-Do had not yet reached feature parity with Wunderlist, with its team citing that the service had to be completely re-written to use Microsoft Azure instead of Amazon Web Services. Frustrated by the perceived lack of roadmap, in September 2019, Reber began to publicly ask Microsoft-related accounts on Twitter whether he could buy Wunderlist back. Shortly afterward, however, Microsoft unveiled updates to To-Do that make it more closely resemble Wunderlist. In December 2019, Microsoft announced that it would fully shut down Wunderlist as of May 6, 2020. The team responsible for creating Wunderlist, led by co-founder Christian Reber, created that Superlist app in early 2024. == Finances == In its initial round of funding, 100,000 euro was invested in 6Wunderkinder by Frank Thelen and others. In December 2010, High-Tech Gründerfonds invested 500,000 euro (approximately US$660,000) in the company. T-Venture also invested an undisclosed amount in the startup. In its Series A round of funding in November 2011, Atomico invested $4.2 million (~$5.76 million in 2024) while High-Tech Gründerfonds invested an undisclosed additional amount. In May 2012, High-Tech Gründerfonds sold off its stake in 6Wunderkinder to Earlybird Venture Capital. In November 2013, $19 million (~$25.2 million in 2024) was raised in a Series B round led by Sequoia Capital with participation from Earlybird and Atomico. == Awards == In 2013, Wunderlist for Mac was named App of the Year. Wunderlist was selected as a Google Play Top Developer in 2013. In 2014, Wunderlist won the "Golden Mi" award from Xiaomi, and also named as one of its Best Apps of 2014 was given a "Google Play Editor's Choice" award, and was named in Google Play's Best Apps of 2014 as well as Apple's Best of 2014.
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 →
Web Dynpro

Web Dynpro (WD) is a web application technology developed by SAP SE that focuses on the development of server-side business applications. For modern releases (for instance as of NetWeaver 750, software layer SAP_UI) the user interface is rendered according to the HTML5 web standard. Since Netweaver 754 (software layer SAP_UI, ABAP Platform 1909) a touch enabled user interface is available. The newly released versions usually follow the SAP Fiori design principles. One of its main design features is that the user interface is defined in an entirely declarative manner. Web Dynpro applications can be developed using either the Java (Web Dynpro for Java, WDJ or WD4J) or ABAP (Web Dynpro ABAP, WDA or WD4A) development infrastructure. == Overview == The earliest version of Web Dynpro appeared in 2003 and was based on Java. This variant was released approximately 18 months before the ABAP variant. As of 2010, the Java variant of Web Dynpro was put into maintenance mode. WD follows a design architecture based on an interpretation of the MVC design pattern and uses a model driven development approach ("minimize coding, maximize design"). The Web Dynpro Framework is a server-side runtime environment into which many dedicated "hook methods" are available. The developer then places their own custom coding within these hook methods in order to implement the desired business functionality. These hook methods belong to one of the broad categories of either "life-cycle" and "round-trip"; that is, those methods that are concerned with the life-cycle of a software component (i.e. processing that takes place at start up and shut down etc.), and those methods that are concerned with processing the fixed sequence of events that take place during a client-initiated round trip to the server. Web Dynpro is aimed at the development of business applications that follow standardized UI principles, applications that connect to backend systems and which are scalable. Key Capabilities Declarative way of development: Web Dynpro offers a graphical and declarative means of UI development. UI controls, building blocks, views and windows are modeled, and the business logic can be coded separately. Separation of user interface and business logic: One advantage of Web Dynpro over SAP GUI is the separation between business logic and user interface, and the structured development process with less implementation effort. Support of stateful application: The state of the application is kept in the back-end. This leads to a reduced data transfer from ABAP server to browser and vice versa. Regarding Web Dynpro ABAP there is only one programming language (ABAP) and only one system necessary. Therefore, development can be easier and cost efficient.
Read more →
Round-trip engineering

Round-trip engineering (RTE) in the context of model-driven architecture is a functionality of software development tools that synchronizes two or more related software artifacts, such as, source code, models, configuration files, documentation, etc. between each other. The need for round-trip engineering arises when the same information is present in multiple artifacts and when an inconsistency may arise in case some artifacts are updated. For example, some piece of information was added to/changed in only one artifact (source code) and, as a result, it became missing in/inconsistent with the other artifacts (in models). == Overview == Round-trip engineering is closely related to traditional software engineering disciplines: forward engineering (creating software from specifications), reverse engineering (creating specifications from existing software), and reengineering (understanding existing software and modifying it). Round-trip engineering is often wrongly defined as simply supporting both forward and reverse engineering. In fact, the key characteristic of round-trip engineering that distinguishes it from forward and reverse engineering is the ability to synchronize existing artifacts that evolved concurrently by incrementally updating each artifact to reflect changes made to the other artifacts. Furthermore, forward engineering can be seen as a special instance of RTE in which only the specification is present and reverse engineering can be seen as a special instance of RTE in which only the software is present. Many reengineering activities can also be understood as RTE when the software is updated to reflect changes made to the previously reverse engineered specification. === Types === Various books describe two types of RTE: partial or uni-directional RTE: changes made to a higher level representation of a code and model are reflected in lower level, but not otherwise; the latter might be allowed, but with limitations that may not affect higher-level abstractions full or bi-directional RTE: regardless of changes, both higher and lower-level code and model representations are synchronized if any of them altered === Auto synchronization === Another characteristic of round-trip engineering is automatic update of the artifacts in response to automatically detected inconsistencies. In that sense, it is different from forward- and reverse engineering which can be both manual (traditionally) and automatic (via automatic generation or analysis of the artifacts). The automatic update can be either instantaneous or on-demand. In instantaneous RTE, all related artifacts are immediately updated after each change made to one of them. In on-demand RTE, authors of the artifacts may concurrently update the artifacts (even in a distributed setting) and at some point choose to execute matching to identify inconsistencies and choose to propagate some of them and reconcile potential conflicts. === Iterative approach === Round trip engineering may involve an iterative development process. After you have synchronized your model with revised code, you are still free to choose the best way to work – make further modifications to the code or make changes to your model. You can synchronize in either direction at any time and you can repeat the cycle as many times as necessary. == Software == Many commercial tools and research prototypes support this form of RTE; a 2007 book lists Rational Rose, Together, ESS-Model, BlueJ, and Fujaba among those capable, with Fujaba said to be capable to also identify design patterns. == Limitations == A 2005 book on Visual Studio notes for instance that a common problem in RTE tools is that the model reversed is not the same as the original one, unless the tools are aided by leaving laborious annotations in the source code. The behavioral parts of UML impose even more challenges for RTE. Usually, UML class diagrams are supported to some degree; however, certain UML concepts, such as associations and containment do not have straightforward representations in many programming languages which limits the usability of the created code and accuracy of code analysis/reverse engineering (e.g., containment is hard to recognize in the code). A more tractable form of round-trip engineering is implemented in the context of framework application programming interfaces (APIs), whereby a model describing the usage of a framework API by an application is synchronized with that application's code. In this setting, the API prescribes all correct ways the framework can be used in applications, which allows precise and complete detection of API usages in the code as well as creation of useful code implementing correct API usages. Two prominent RTE implementations in this category are framework-specific modeling languages and Spring Roo (Java). Round-trip engineering is critical for maintaining consistency among multiple models and between the models and the code in Object Management Group's (OMG) Model-driven architecture. OMG proposed the QVT (query/view/transformation) standard to handle model transformations required for MDA. To date, a few implementations of the standard have been created. (Need to present practical experiences with MDA in relation to RTE). == Controversies == === Code generation controversy === Code generation (forward-engineering) from models means that the user abstractly models solutions, which are connoted by some model data, and then an automated tool derives from the models parts or all of the source code for the software system. In some tools, the user can provide a skeleton of the program source code, in the form of a source code template where predefined tokens are then replaced with program source code parts during the code generation process. UML (if used for MDA) diagrams specification was criticized for lack the detail which is needed to contain the same information as is covered with the program source. Some developers even claim that "the Code is the design". == Disadvantages == There is a serious risk that the generated code will rapidly differ from the model or that the reverse-engineered model will lose its reflection on the code or a mix of these two problems as result of cycled reengineering efforts. Regarding behavioral/dynamic part of UML for features like statechart diagram there is no equivalents in programming languages. Their translation during code-generation will result in common programming statement (.e.g if,switch,enum) being either missing or misinterpreted. If edited and imported back may result in different or incomplete model. The same goes for code snippets used for code generation stage for the pattern-implementation and user-specific logic: intermixed they may not be easily reverse-engineered back. There is also general lack of advanced tooling for modelling that are comparable to that of modern IDEs (for testing, debugging, navigation, etc.) for general-purpose programming languages and domain-specific languages. == Examples in software engineering == Perhaps the most common form of round-trip engineering is synchronization between UML (Unified Modeling Language) models and the corresponding source code and entity–relationship diagrams in data modelling and database modelling. Round-trip engineering based on Unified Modeling Language (UML) needs three basic tools for software development: Source Code Editor; UML Editor for the Attributes and Methods; Visualisation of UML structure
Read more →
Cloud load balancing

Cloud load balancing is a type of load balancing that is performed in cloud computing. Cloud load balancing is the process of distributing workloads across multiple computing resources. Cloud load balancing reduces costs associated with document management systems and maximizes availability of resources. It is a type of load balancing and not to be confused with Domain Name System (DNS) load balancing. While DNS load balancing uses software or hardware to perform the function, cloud load balancing uses services offered by various computer network companies. == Comparison With DNS load balancing == Cloud load balancing has an advantage over DNS load balancing as it can transfer loads to servers globally as opposed to distributing it across local servers. In the event of a local server outage, cloud load balancing delivers users to the closest regional server without interruption for the user. Cloud load balancing addresses issues relating to TTL reliance present during DNS load balancing. DNS directives can only be enforced once in every TTL cycle and can take several hours if switching between servers during a lag or server failure. Incoming server traffic will continue to route to the original server until the TTL expires and can create an uneven performance as different internet service providers may reach the new server before other internet service providers. Another advantage is that cloud load balancing improves response time by routing remote sessions to the best performing data centers. == Importance of Load Balancing == Cloud computing brings advantages in "cost, flexibility and availability of service users." Those advantages drive the demand for Cloud services. The demand raises technical issues in Service Oriented Architectures and Internet of Services (IoS)-style applications, such as high availability and scalability. As a major concern in these issues, load balancing allows cloud computing to "scale up to increasing demands" by efficiently allocating dynamic local workload evenly across all nodes. == Load Balancing Techniques == === Scheduling Algorithms === Opportunistic Load Balancing (OLB) is the algorithm that assigns workloads to nodes in free order. It is simple but does not consider the expected execution time of each node. Load balance Min-Min (LBMM) assigns sub-tasks to the node which requires minimum execution time. === Load Balancing Policies === Workload and Client Aware Policy (WCAP) specifies the unique and special property (USP) of requests and computing nodes. With the information of USP, the schedule can decide the most suitable node to complete a request. WCAP makes the most of computing nodes by reducing their idle time. Also, it reduces performance time through searches based on content information. === A Comparative Study of Algorithms === Biased Random Sampling bases its job allocation on the network represented by a directed graph. For each execution node in this graph, in-degree means available resources and out-degree means allocated jobs. In-degree will decrease during job execution while out-degree will increase after job allocation. Active Clustering is a self-aggregation algorithm to rewire the network. The experiment result is that"Active Clustering and Random Sampling Walk predictably perform better as the number of processing nodes is increased" while the Honeyhive algorithm does not show the increasing pattern. == Client-side Load Balancer Using Cloud Computing == Load balancer forwards packets to web servers according to different workloads on servers. However, it is hard to implement a scalable load balancer because of both the "cloud's commodity business model and the limited infrastructure control allowed by cloud providers." Client-side Load Balancer (CLB) solve this problem by using a scalable cloud storage service. CLB allows clients to choose back-end web servers for dynamic content although it delivers static content.
Read more →
DreamLab

DreamLab was a volunteer computing Android and iOS app launched in 2015 by Imperial College London and the Vodafone Foundation. It was discontinued on 2nd April 2025. == Description == The app helped to research cancer, COVID-19, new drugs and tropical cyclones. To do this, DreamLab accessed part of the device's processing power, with the user's consent, while the owner charged their smartphone, to speed up the calculations of the algorithms from Imperial College London. The aim of the tropical cyclone project was to prepare for climate change risks. Other projects aimed to find existing drugs and food molecules that could help people with COVID-19 and other diseases. The performance of 100,000 smartphones would reach the annual output of all research computers at Imperial College in just three months, with a nightly runtime of six hours. The app was developed in 2015 by the Garvan Institute of Medical Research in Sydney and the Vodafone Foundation. In May 2020, the project had over 490,000 registered users.
Read more →
Twproject

Twproject (say: T W Project) is a web-based project and groupware management tool created by Open Lab, an Italian software house founded in 2001. It won the 17th Jolt Productivity Award in 2007 in the project management category. In March 2019 it becomes property of Twproject company. It has widespread use in universities as a teaching tool in project management courses. It is used by Oracle Corporation, Prada, Calzedonia, General Electric and many other companies from corporations to small start-ups. == History == April 2001 - The idea of Teamwork came to Open-Lab founders from a need to overcome the PM tools used at that time. It was built in Microsoft ASP and Adobe Flash November 2002 - Open-Lab decide to move from Flash to HTML and from ASP to Java-JSP. Teamwork 2 development is started. June 2004 - Teamwork 2 released, using top open-source technologies like Hibernate, jBlooming, dynamic CSS, Ajax 7 January 2005 - Teamwork goes open source, under LGPL license; remains such until June 2006 (18 months): it is a hit application on SourceForge, with 38.000 downloads, covered by greeting but starving April 2005 - Open-Lab takes the decision to change commercial strategy to finance development of Teamwork version 3 6 June 2006 - Teamwork 3 is finally out (15 months development). New interface, many new features, agile support and much more 27 March 2007 - Teamwork wins the 2007 JOLT Productivity Awards for project management category July 2007 - Teamwork 4 development started: new interface, extended use of new HTML capabilities, JS-oriented interface, start using jQuery February 2009 - Teamwork 4.0 is out February 2010 - Teamwork 4.4: public project pages, Chinese interface. jQuery is getting more space in Teamwork December 2010 - Teamwork 4.6: released Mobile module available for iPhone, Android, BlackBerry. Intensive usage of jQuery June 2011 - Teamwork 4.7: released Issue Kanban / Organizer January 2012 - Teamwork 5.0 development started. Lighter interface, extensive usage of dynamic pages, easier installer and first time approach. Learning curve highly reduced. A jQuery Gantt editor included and released free for the community July 2012 - Teamwork 5 released and also the free online Gantt editor November 2012 - Teamwork 5.1 with new trees and improved model for staffing March 2013 - Teamwork 5.2 with stronger support for customizations and Japanese interface. April 2014 - Teamwork has changed its name in Twproject because the domain teamwork.com has been purchased by Teamwork. April 2013 - Twproject 5.4 with a redesigned more powerful Gantt chart. August 2015 - Twproject 5 finale release. September 2015 - Twproject 6 with a completely redesigned user interface. March 2019 - A new company Twproject srl has been spun off. September 2021 - Twproject 7 has been released introducing WBS based management and workload management. == Features == Project & task management (with Microsoft Project import/export), and JSON format Gantt editor. Uses jQuery Gantt components Time tracking. Several entry points: dashboard, weekly view, issues, start/stop buttons Resource planning with weekly/monthly view, work load overview, unavailability from agenda Issue tracking & planning(with Kanban), e-mail integration, task dedicated inboxes Dashboard configuration, with customizable portlets and layout Message boards Scrum module Meeting and minute management, attached documents Agenda (Integrates with iCal, Microsoft Outlook, Microsoft Entourage, and Google Calendar) Document management, remote file systems link with NTFS, FTP, SVN, S3 (Dropbox, Google drive) Mobile application for iPhone, iPad, Android, Blackberry, Windows phone == Integration == A complete JSON API is available for integrations. The applications runs in Java JDK 8+ on the Hibernate object/relational mapping. The standard distribution uses Apache Tomcat 9, but can run on any J2EE application server. Twproject is tested on these DB servers: MySQL, Oracle, SQL Server, PostgreSql, HSQLDB, but as uses Hibernate can run on many others. There is simple graphical step-by-step installer for Windows, Mac, Linux, .zip/.tar.gz/.rpm packages.
Read more →
Real-Time UML

Real-Time UML (RTUML) refers to the application of the Unified Modelling Language (UML) for the analysis, design, and implementation of real-time and embedded systems, where timing constraints, concurrency, and resource management are critical. It extends standard UML with profiles, notations, and semantics to handle hard and soft real-time requirements, such as modelling predictable response times and fault tolerance. RTUML is not a separate language but a methodology leveraging UML diagrams (e.g., statecharts, sequence diagrams) for time-sensitive applications like automotive controls, avionics, and medical devices. The term is closely associated with Bruce Powel Douglass, who popularised it through his books and the Harmony process for embedded software development. As of 2025, RTUML remains relevant in industries requiring certified systems, though its adoption varies with agile methodologies and model-driven engineering tools. == Background == Real-Time UML emerged in the late 1990s as UML was standardized by the Object Management Group (OMG) in 1997, addressing the need for object-oriented modeling in real-time systems previously dominated by procedural languages like C. Traditional real-time development relied on "bare metal" programming or theoretical models, but RTUML introduced visual notations for object structure, behaviour, and timing. Bruce Powel Douglass’s 1999 book, Real-Time UML: Developing Efficient Objects for Embedded Systems, formalised the approach, emphasising statecharts for concurrency and timing constraints. Later editions (2004, 2006) incorporated UML 2.0 features like activity and timing diagrams, aligning with OMG’s Real-Time Profile (now part of MARTE—Modelling and Analysis of Real-Time and Embedded Systems). The Harmony process integrates RTUML with executable models for simulation and code generation. RTUML addresses hard real-time systems (e.g., strict deadlines in avionics) versus soft real-time (e.g., media streaming), using UML extensions for schedulability analysis. == Key concepts == RTUML adapts UML diagrams and techniques for real-time needs: Statecharts and Behaviour Modelling: Extended state machines model reactive behaviour, using and-states for concurrency, pseudostates for transitions, and timing constraints (e.g., {duration < 10ms}). Examples include cardiac pacemaker models. Sequence and Interaction Diagrams: Capture message timing, priorities, and resource allocation in multi-threaded systems. Architectural Patterns: Define logical and physical architectures with active objects for concurrency and patterns like observer or publisher-subscriber. Timing and Constraints: Use Object Constraint Language (OCL) for specifying deadlines and priorities. Profiles and Extensions: OMG’s UML Profile for Schedulability, Performance, and Time (SPT) and MARTE add stereotypes like RT::ActiveObject. These support iterative development, from requirements to deployment, often with tools like IBM Rhapsody or Enterprise Architect. == Applications == RTUML is used in: Embedded Systems: Modelling automotive ECUs or UAV controls. Avionics and Defence: DO-178C-compliant designs for fault tolerance. Medical Devices: Pacemakers or ventilators with precise timing. Industrial Automation: RTOS task visualisation via sequence diagrams. Tools like IBM Rhapsody support RTUML for model-based development and code generation in C/C++. == Criticism and adoption == RTUML’s complexity can overwhelm simple systems, and its use in agile environments is limited, where lightweight diagrams are preferred. Surveys indicate UML (including RTUML) is used in 30–50% of embedded projects, often for documentation rather than full model-driven engineering. It remains standard in academia and certified industries like aerospace.
Read more →