ZeroPC was a commercial webtop developed by ZeroDesktop, Inc. located in San Mateo, California. ZeroPC has been called a personal cloud OS. It mimicked the look, feel and functionality of the desktop environment of a real operating system. The software was launched in September 2011 through Disrupt SF 2011 event and recently selected to the finalist of SXSW 2012 in Innovative Web Technology category. ZeroPC is web-based and required a Java applet to operate bundled productivity tool Thinkfree. The web applications found on ZeroPC are built on Java in the back end. Features included drag-and-drop functionality, cloud dashboard and personal cloud storage meta services. ZeroPC belonged to a category of services that intended to turn the Web into a full-fledged platform by using Web services as a foundation along with presentation technologies that replicated the experience of desktop applications for users. ZeroPC aggregates content so users can easily access, transfer and share whatever content they want, using a web browser from any device. Its meta-cloud layer supports Dropbox, Box, SugarSync, OneDrive, 4Shared, Google Drive, Evernote, Picasa, Flickr, Instagram, Facebook, Twitter, and Photobucket. ZeroPC Cloud OS platform also provides extensive APIs for iOS and Android App developers. Some of the features found on ZeroPC are: File sharing, Webmail, Cloud Content Navigator, Instant messenger, Sticky Note, Audio/Video Player and Office productivity applications. ZeroPC 2.0 platform ran on AWS for free and paid users. Its platform is licensable to Telco and ISV for commercial purpose. Their clients are SFR, SK Telecom, Hancom and others. As of June 1, 2017, ZeroPC's servers were switched off completely, and ZeroPC is no longer in service since its parent company, NComputing, had launched Virtual Desktop Service in the cloud (AWS) to public. == Browser and Platform Compatibility == The ZeroPC web desktop was compatible with Mac OS X and Microsoft Windows platforms. It is certified to operate on Safari 6.0, Firefox 15.0.1, Google Chrome 22.0.1229.79 m and Internet Explorer 8 and 9. The ZeroPC front end user interface executes entirely within a web browser (see above) and uses HTML, some features of HTML5, JavaScript, AJAX and an optional Java plug-in. == Security == All communication between the ZeroPC front end user interface and the ZeroPC back end servers is encrypted using SSL (HTTPS) protocol. Furthermore, any content stored in the ZeroPC server-side repository is also encrypted using 256-bit Advanced Encryption Standard (AES-256) by Amazon S3 on AWS. ZeroPC users could connect their ZeroPC profile to other storage services such as Dropbox and Box. This connection allows the ZeroPC user to fully manage their content stored in these other storage services. To establish the connection ZeroPC rigorously adhered to the Oauth implementation provided by the target storage service. Upon completion of the Oauth process, ZeroPC stores the relevant access token in the user's profile. This token, along with all other sensitive password related data was encrypted using AES 256-bit key size. == Implementations == As noted above, the ZeroPC platform was hosted on Amazon Web Services infrastructure and is available to the general consumer. A user was allowed to sign up by selecting one of three account plans including a no-cost option. The ZeroPC could also be white-labeled for organizations wishing to provide this functionality to their own users. The white-label options include managed hosting on Amazon Web Services infrastructure and also installation within the organization's IT infrastructure. == User Access Points == The ZeroPC infrastructure provided user access to content and features in several different ways. As described in this article the user can access their information by signing into the ZeroPC web desktop. Additionally, ZeroPC offers native applications designed to run on popular mobile devices including smartphones and tablets. == Leadership == ZeroPC was founded by Chief Executive Officer, Young Song, an entrepreneur who previously founded NComputing, a $60 million venture-backed company. He also co-founded eMachines, Inc., a low-cost computer brand (later acquired by Gateway).
Cloud testing
Cloud testing is a form of software testing in which web applications use cloud computing environments (a "cloud") to simulate real-world user traffic. == Steps == Companies simulate real world Web users by using cloud testing services that are provided by cloud service vendors such as Advaltis, Compuware, HP, Keynote Systems, Neotys, RadView and SOASTA. Once user scenarios are developed and the test is designed, these service providers leverage cloud servers (provided by cloud platform vendors such as Amazon.com, Google, Rackspace, Microsoft, etc.) to generate web traffic that originates from around the world. Once the test is complete, the cloud service providers deliver results and analytics back to corporate IT professionals through real-time dashboards for a complete analysis of how their applications and the internet will perform during peak volumes. == Applications == Cloud testing is often seen as only performance or load tests, however, as discussed earlier it covers many other types of testing. Cloud computing itself is often referred to as the marriage of software as a service (SaaS) and utility computing. In regard to test execution, the software offered as a service may be a transaction generator and the cloud provider's infrastructure software, or may just be the latter. Distributed Systems and Parallel Systems mainly use this approach for testing, because of their inherent complex nature. D-Cloud is an example of such a software testing environment. == Tools == Leading cloud computing service providers include, among others, Amazon, Microsoft, Google, RadView, Skytap, HP and SOASTA. == Benefits == The ability and cost to simulate web traffic for software testing purposes has been an inhibitor to overall web reliability. The low cost and accessibility of the cloud's extremely large computing resources provides the ability to replicate real world usage of these systems by geographically distributed users, executing wide varieties of user scenarios, at scales previously unattainable in traditional testing environments. Minimal start-up time along with quality assurance can be achieved by cloud testing. Following are some of the key benefits: Reduction in capital expenditure Highly scalable
SWIG
The Simplified Wrapper and Interface Generator (SWIG) is an open-source software tool used to connect computer programs or libraries written in C or C++ with scripting languages such as Lua, Perl, PHP, Python, R, Ruby, Tcl, and other language implementations like C#, Java, JavaScript, Go, D, OCaml, Octave, Scilab and Scheme. Output can also be in the form of XML. == Function == The aim is to allow the calling of native functions (that were written in C or C++) by other programming languages, passing complex data types to those functions, keeping memory from being inappropriately freed, inheriting object classes across languages, etc. The programmer writes an interface file containing a list of C/C++ functions to be made visible to an interpreter. SWIG will compile the interface file and generate code in regular C/C++ and the target programming language. SWIG will generate conversion code for functions with simple arguments; conversion code for complex types of arguments must be written by the programmer. The SWIG tool creates source code that provides the glue between C/C++ and the target language. Depending on the language, this glue comes in three forms: a shared library that an extant interpreter can link to as some form of extension module, or a shared library that can be linked to other programs compiled in the target language (for example, using Java Native Interface (JNI) in Java). a shared dynamic library source code that should be compiled and dynamically loaded (e.g. Node.js native extensions) SWIG is not used for calling interpreted functions by native code; this must be done by the programmer manually. == Example == SWIG wraps simple C declarations by creating an interface that closely matches the way in which the declarations would be used in a C program. For example, consider the following interface file: In this file, there are two functions sin() and strcmp(), a global variable Foo, and two constants STATUS and VERSION. When SWIG creates an extension module, these declarations are accessible as scripting language functions, variables, and constants respectively. In Python: == Purpose == There are two main reasons to embed a scripting engine in an existing C/C++ program: The program can then be customized far faster, via a scripting language instead of C/C++. The scripting engine may even be exposed to the end-user, so that they can automate common tasks by writing scripts. Even if the final product is not to contain the scripting engine, it may nevertheless be very useful for writing test scripts. There are several reasons to create dynamic libraries that can be loaded into extant interpreters, including: Provide access to a C/C++ library which has no equivalent in the scripting language. Write the whole program in the scripting language first, and after profiling, rewrite performance-critical code in C or C++. == History == SWIG is written in C and C++ and has been publicly available since February 1996. The initial author and main developer was David M. Beazley who developed SWIG while working as a graduate student at Los Alamos National Laboratory and the University of Utah and while on the faculty at the University of Chicago. Development is currently supported by an active group of volunteers led by William Fulton. SWIG has been released under a GNU General Public License. == Google Summer of Code == SWIG was a successful participant of Google Summer of Code in 2008, 2009, 2012. In 2008, SWIG got four slots. Haoyu Bai spent his summers on SWIG's Python 3.0 Backend, Jan Jezabek worked on Support for generating COM wrappers, Cheryl Foil spent her time on Comment 'Translator' for SWIG, and Maciej Drwal worked on a C backend. In 2009, SWIG again participated in Google Summer of Code. This time four students participated. Baozeng Ding worked on a Scilab module. Matevz Jekovec spent time on C++0x features. Ashish Sharma spent his summer on an Objective-C module, Miklos Vajna spent his time on PHP directors. In 2012, SWIG participated in Google Summer of Code. This time four out of five students successfully completed the project. Leif Middelschulte worked on a C target language module. Swati Sharma enhanced the Objective-C module. Neha Narang added the new module on JavaScript. Dmitry Kabak worked on source code documentation and Doxygen comments. == Alternatives == For Python, similar functionality is offered by SIP, Pybind11, and Boost's Boost.python library. == Projects using SWIG == ZXID (Apache License, Version 2.0) Symlabs SFIS (commercial) LLDB GNU Radio up to (including) version 3.8.x.x; later versions use Pybind11 Xapian TensorFlow Apache SINGA QuantLib Babeltrace
CPT Corporation
CPT Corporation was founded in 1971 by Dean Scheff in Minneapolis, Minnesota, with co-founders James Wienhold and Richard Eichhorn. CPT first designed, manufactured, and marketed the CPT 4200, a dual-cassette-tape machine that controlled a modified IBM Selectric typewriter to support text editing and word processing. The CPT 4200 was followed in 1976 by the CPT VM (Visual Memory), a partial-page display-screen dual-cassette-tape unit, and shortly thereafter by the CPT 8000, a full-page display dual-diskette desktop microcomputer that drove stand-alone daisy wheel printers. Subsequent products included (1) variants on the 8000 series; (2) the CPT 6000 series, which had a lower capacity, smaller screen, and was less expensive; (3) the CPT 9000 series, which had a larger capacity and could run IBM personal computer software; (4) the CPT Phoenix series, which had a graphical capabilities; (5) CPT PT, a software-only reduced version that ran on IBM personal computers and clones; and (6) other related products. The CPT logo—originally three letters chosen to sound well together—began to be taken as an acronym for "cassette powered typewriting," and subsequently for "computer processed text," and numerous other variants. Major competition was IBM, Wang, Lanier, Xerox, and other word processing vendors. CPT Corporation was fifth in size among Minnesota-based top high-tech companies, after 3M, Honeywell, Control Data, and Medtronic. Corporate revenues grew to approximately a quarter-billion dollars per year in the mid-1980s, then declined with the proliferation of personal computers. CPT ultimately ceased major manufacturing late in the 20th century. == Selected products == === Cassette based === The CPT 4200 was a dual-cassette-tape unit with a small built-in keyboard that controlled a modified IBM Selectric typewriter. Keystrokes entered on the typewriter appeared on the paper as they were recorded on the output cassette, which formed a magnetic replica of the characters printed on the page. That output cassette could later be used as an input cassette, where it would be played back to the typewriter along with new keystrokes to accomplish text editing. The keyboard of the CPT 4200 had action keys for "skip", "read" and "stop", mode keys for "word", "line", "paragraph," and "page." Pressing "read" transferred a word, line, paragraph, or page (depending on which mode key had been selected) from the input tape to both the typewriter and the output tape. Line boundaries (aka printer margins) recorded on the input tape were ignored or retained depending on whether or not the "adjust" key had been selected. Alternatively, pressing "skip" moved past the corresponding amount of text on the input tape without sending it to the typewriter or to the output tape. The Selectric's keyboard was active for any new typing, which would appear on the paper and transferred to the output tape. Thus a document was edited by reading back those parts of the text to be retained and skipping those parts to be discarded, with new typing added from the Selectric's keyboard. Price: approx. $5000, 1980-era values. The CPT Communicator was an add-on to the CPT 4200 that allowed data to be transferred from one text-editing machine to another, or between a text-editing machine and a remote computer, via phone lines. Price: not available. === Microprocessor based === ==== CPT 8000 series ==== The CPT 8000 was the company's first microcomputer product, exhibited in spring of 1976. It was a self-contained desktop machine with two 8-inch floppy diskette drives, a movable keyboard, and a full-page vertically oriented CRT display simulating paper with black characters on a white background, for a wysiwyg view of text on paper. It was promoted as familiar and easy to use for those experienced with typewriters. A keyboard with a large set of extra keys made operating the 8000 quite easy even for people without any computer skills or background. IN, OUT, PRINT, OOPS OOPS was changed thinking it was insulting to the buyer to assume they would ever make an error. The CPT 8000 was designed to show a full page of text with a static line showing the margin and tab stops. An additional line would display status or error messages with a times square like display. The times square error and status messages were very well done, "The printer needs a new ribbon" rather than "ERROR 034892". The text page could both smooth pan and scroll by the hardware in the display board and nothing quite like it existed for a very long time. The 8000 ran its own multitasking hardware interrupt-driven operating system but it also ran CP/M quite well. So unlike other companies that sold Wordprocessor only systems, CPT had a system that could run any of the many popular CP/M applications. Using the CP/M OS users could develop Fortran, CBasic, Cobol and other language's programs. The 8000 used Intel's 8080 microprocessor. The display board was bleeding-edge, high-speed logic. The parts available at this time were pushed to their limits to provide the speed needed to display this much text. There were times that batches of parts from one manufacturer simply could not be clocked as fast as the 8000 display required. Memory was initially 64K, but larger boards of 128K were most common then later 256K were offered. The 8080 accessed this additional RAM by running a custom page flipping circuit. The 8000 was originally priced at $8000 and its daisy wheel printer an additional $8000. The model number having been confused with the price at its first appearance at the Hanover fair. An RS-232 serial communication option was available for the 8000 series that allowed the electronic transfer of documents. One very popular use of this was to access the Westlaw system. A tempest approved version of the 8000 was developed that was RF tight with nothing being emitted that could be monitored or spied on. === Storage Systems === ==== CPT WordPak ==== The CPT WordPak series was CPT's first external document storage system that enabled multiple 8000 series workstations to store documents in an electronic filing cabinet. Prior to WordPak, all documents were stored on removable 8-inch floppy diskettes. Sharing documents involved handing off the original disk, or copying the document to a second disk and 'sneaker-net-ing' (walking it over) to the second 8000. But this resulted in two copies of the document, one at each workstation. A circuit board with a proprietary cable connector was installed in the 8000/6000 family of "workstations" and connected to the WordPak by a multi-conductor cable. WordPak 1 consisted of a single Shugart Associates SA4000 14"-diameter hard disk with a capacity of 30 megabytes. WordPak 2 added a 2nd drive for a total of 60 megabytes. ==== CPT SRS 45 ==== The CPT SRS 45 was what would now be called a server (quite likely the first of its kind) but in practice was much more. It was maybe the worlds easiest networking shared resource system. It combined a ZIP drive for backup and hard disk(s) that would be shared simultaneously by up to eight CPT machines that had the PC AT bus. The primary person responsible for its development was Bill Davidson whose wife Cheryl was responsible for bringing up CP/M, MP/M and other Digital Research products running on the Phoenix. The brilliance of the system were the networking cards that plugged into the individual machines. These used the 55AA installable driver of the IBM BIOS to simply add the zip and hard disk drives to each computers drives list. So a system that started with floppy drives A and B and a C hard disk on the machine would have the SRS 45 drives added as drives D (E, F depending on the number of hard disk) and Z for the zip drive. Sharing (avoiding writing to the same file at the same time) was handled by simply assigning parts of the drives for individuals and other directories for shared use. No "driver" software was needed. You simply plugged in the networking card and your machine had additional drives that were internal to the SRS45. This approach was far ahead of its time and sadly never recognized for its brilliance. The SRS45 as were all CPT machines not just dedicated Word Processors. === Personal-computer based === ==== CPT PT software ==== CPT PT was a reduced a version of the software that ran under MS-DOS as an application on IBM PC compatible computers. The corporation intended it as a bridge to allow data to flow in and out of personal computer packages, as well as providing a personal-computer word processing application for those familiar with standalone CPT equipment or who preferred the CPT style of dual-window text editing. Price: approx. $200, 1980-era values. ==== CPT Genius Display ==== The Genius display was a stand-alone, vertically-oriented (portrait) configuration monochrome grey-scale CRT monitor unit and an IBM PC form factor display card to allow high-resolution, full-page text & graphics on IBM PC compatible computers.
Box blur
A box blur (also known as a box linear filter) is a spatial domain linear filter in which each pixel in the resulting image has a value equal to the average value of its neighboring pixels in the input image. It is a form of low-pass ("blurring") filter. A 3 by 3 box blur ("radius 1") can be written as matrix 1 9 [ 1 1 1 1 1 1 1 1 1 ] . {\displaystyle {\frac {1}{9}}{\begin{bmatrix}1&1&1\\1&1&1\\1&1&1\end{bmatrix}}.} Due to its property of using equal weights, it can be implemented using a much simpler accumulation algorithm, which is significantly faster than using a sliding-window algorithm. Box blurs are frequently used to approximate a Gaussian blur. By the central limit theorem, repeated application of a box blur will approximate a Gaussian blur. In the frequency domain, a box blur has zeros and negative components. That is, a sine wave with a period equal to the size of the box will be blurred away entirely, and wavelengths shorter than the size of the box may be phase-reversed, as seen when two bokeh circles touch to form a bright spot where there would be a dark spot between two bright spots in the original image. == Extensions == Gwosdek, et al. has extended Box blur to take a fractional radius: the edges of the 1-D filter are expanded with a fraction. It makes slightly better gaussian approximation possible due to the elimination of integer-rounding error. Mario Klingemann has a "stack blur" that tries to better emulate gaussian's look in one pass by stacking weights: 1 9 [ 1 2 3 2 1 ] {\displaystyle {\frac {1}{9}}{\begin{bmatrix}1&2&3&2&1\end{bmatrix}}} The triangular impulse response it forms decomposes to two rounds of box blur. Stacked Integral Image by Bhatia et al. takes the weighted average of a few box blurs to fit the gaussian response curve. == Implementation == The following pseudocode implements a 3x3 box blur. The example does not handle the edges of the image, which would not fit inside the kernel, so that these areas remain unblurred. In practice, the issue is better handled by: Introducing an alpha channel to represent the absence of colors; Extending the boundary by filling in values, ranked by quality: Fill in a mirrored image at the border Fill in a constant color extending from the last pixel Pad in a fixed color A number of optimizations can be applied when implementing the box blur of a radius r and N pixels: The box blur is a separable filter, so that only two 1D passes of averaging 2 r + 1 pixels will be needed, one horizontal and one vertical, for each pixel. This lowers the complexity from O(Nr2) to O(Nr). In digital signal processing terminology, each pass is a moving-average filter. Accumulation. Instead of discarding the sum for each pixel, the algorithm re-uses the previous sum, and updates it by subtracting away the old pixel and adding the new pixel in the blurring range. A summed-area table can be used similarly. This lowers the complexity from O(Nr) to O(N). When being used in multiple passes to approximate a Gaussian blur, the cascaded integrator–comb filter construction allows for doing the equivalent operation in a single pass.
ArcSoft ShowBiz
ShowBiz is a video editor by ArcSoft for the Windows operating system. It can create VCD and DVDs and can also export to the formats AVI, MPEG, WMV, and MOV. ShowBiz also contains a DVD burning and menu building feature. As of 2003, it was one of the three most dominant bundled titles. == Reception == PC Magazine reviewer Jan Ozer states: "ArcSoft's ShowBiz has evolved into a competent editor that's generally more usable than Dazzle's MovieStar program, providing more configuration controls, better preview features, and a much greater range of fun effects." John Virata, senior editor of Digital Media Online, says in his three page review of ShowBiz DVD 2, "It is an easy editor to work with and has a logically laid out interface that takes you step by step through the video creation and DVD creation process"
ReactiveX
ReactiveX (Rx, also known as Reactive Extensions) is a software library originally created by Microsoft that allows imperative programming languages to operate on sequences of data regardless of whether the data is synchronous or asynchronous. It provides a set of sequence operators that operate on each item in the sequence. It is an implementation of reactive programming and provides a blueprint for the tools to be implemented in multiple programming languages. == Overview == ReactiveX is an API for asynchronous programming with observable streams. Asynchronous programming allows programmers to call functions and then have the functions "callback" when they are done, usually by giving the function the address of another function to execute when it is done. Programs designed in this way often avoid the overhead of having many threads constantly starting and stopping. Observable streams (i.e. streams that can be observed) in the context of Reactive Extensions are like event emitters that emit three events: next, error, and complete. An observable emits next events until it either emits an error event or a complete event. However, at that point it will not emit any more events, unless it is subscribed to again. The examples below use the RxJS implementation of Reactive Extensions for the JavaScript programming language. === Motivation === For sequences of data, it combines the advantages of iterators with the flexibility of event-based asynchronous programming. It also works as a simple promise, eliminating the pyramid of doom that results from multiple layers of callbacks. === Observables and observers === ReactiveX is a combination of ideas from the observer and the iterator patterns and from functional programming. An observer subscribes to an observable sequence. The sequence then sends the items to the observer one at a time, usually by calling the provided callback function. The observer handles each one before processing the next one. If many events come in asynchronously, they must be stored in a queue or dropped. In ReactiveX, an observer will never be called with an item out of order or (in a multi-threaded context) called before the callback has returned for the previous item. Asynchronous calls remain asynchronous and may be handled by returning an observable. It is similar to the iterators pattern in that if a fatal error occurs, it notifies the observer separately (by calling a second function). When all the items have been sent, it completes (and notifies the observer by calling a third function). The Reactive Extensions API also borrows many of its operators from iterator operators in other programming languages. Reactive Extensions is different from functional reactive programming as the Introduction to Reactive Extensions explains: It is sometimes called "functional reactive programming" but this is a misnomer. ReactiveX may be functional, and it may be reactive, but "functional reactive programming" is a different animal. One main point of difference is that functional reactive programming operates on values that change continuously over time, while ReactiveX operates on discrete values that are emitted over time. (See Conal Elliott's work for more-precise information on functional reactive programming.) === Reactive operators === An operator is a function that takes one observable (the source) as its first argument and returns another observable (the destination, or outer observable). Then for every item that the source observable emits, it will apply a function to that item, and then emit it on the destination Observable. It can even emit another Observable on the destination observable. This is called an inner observable. An operator that emits inner observables can be followed by another operator that in some way combines the items emitted by all the inner observables and emits the item on its outer observable. Examples include: switchAll – subscribes to each new inner observable as soon as it is emitted and unsubscribes from the previous one. mergeAll – subscribes to all inner observables as they are emitted and outputs their values in whatever order it receives them. concatAll – subscribes to each inner observable in order and waits for it to complete before subscribing to the next observable. Operators can be chained together to create complex data flows that filter events based on certain criteria. Multiple operators can be applied to the same observable. Some of the operators that can be used in Reactive Extensions may be familiar to programmers who use functional programming language, such as map, reduce, group, and zip. There are many other operators available in Reactive Extensions, though the operators available in a particular implementation for a programming language may vary. ==== Reactive operator examples ==== Here is an example of using the map and reduce operators. We create an observable from a list of numbers. The map operator will then multiply each number by two and return an observable. The reduce operator will then sum up all the numbers provided to it (the value of 0 is the starting point). Calling subscribe will register an observer that will observe the values from the observable produced by the chain of operators. With the subscribe method, we are able to pass in an error-handling function, called whenever an error is emitted in the observable, and a completion function when the observable has finished emitting items. ==== Usage in stream-oriented programming ==== Certain RxJS primitives such as BehaviorSubject make it possible to create pure stateful streams to track application state of arbitrary complexity in simple terms. The button below will feed an event to the stream, which in turn will re-emit the next natural number every time, back into the tag that follows and displays the count of clicks detected. Libraries such as Rimmel.js, designed around RxJS Observables, enable integration between reactive streams and the HTML DOM: == History == Reactive Extensions was created by the Cloud Programmability Team at Microsoft around 2011, as a byproduct of a larger effort called Volta. It was originally intended to provide an abstraction for events across different tiers in an application to support tier splitting in Volta. The project's logo represents an electric eel, which is a reference to Volta. The extensions suffix in the name is a reference to the Parallel Extensions technology which was invented around the same time; the two are considered complementary. The initial implementation of Rx was for .NET Framework and was released on June 21, 2011. Later, the team started the implementation of Rx for other platforms, including JavaScript and C++. The technology was released as open source in late 2012, initially on CodePlex. Later, the code moved to GitHub and has been ported to several other languages, including Go, Java, Kotlin, PHP and Rust.