Lokad.CQRS

The business of Lokad is booming, and we are now looking for a Web Marketing Expert. We want to keep developing our inbound marketing strategy, and this person will be reporting directly to the main shareholder of the company (that is, well, myself).

The Lokad facility where the first quantum forecaster prototype is hosted.Delivering more accurate forecasts has been the mission of Lokad since the very beginning. Today, after years of R&D efforts, we are extremely proud to announce the ... [More] immediate availability of new quantum forecasting technology that delivers unprecedented forecast accuracy well beyond the performance routinely achieve by statistical forecasting technologies. This technology leverages several key aspects of quantum mechanics, and in particular the Heisenberg reverse uncertain principle that states that there a fundamental limit to the imprecision of measurements made on the physical properties of particles such as position and momentum. From a demand forecasting viewpoint, it means that by shaping the course of particles to follow the patterns of observed in say, a time-series representing sales over time, the laws of physics guarantee a minimal amount of precision on the measurements to be made when the particles are observed continuing their trajectory beyond the point representing the “present”. Those measurements represent the physical projection of the time-series, that is, in layman terms, the actual demand forecast. Instead of relying on statistics, the quantum forecast leverages the law of physics themselves to produce the forecast. Schema of the Lokad quantum forecaster facility in Ufa, RussiaWhile the implications and benefits of quantum mechanics in terms of forecasting have been known to specialists for decade, the physical design of a quantum forecaster had remained an incredible challenge. A couple of years ago, Lokad opened a large scale facility in Ufa (Russia) to build such a device. It took us a long time to get it built, and an ever longer time to get it properly tuned. In particular, the launch was delayed because quantum interferences caused by the Large Hadron Collider operated by the CERN which proved to be troublesome. The addition of several extra Higgs boson detectors did finally solve the problem. At present time, Lokad is actively working on the miniaturization of the quantum forecaster. We don’t have a public pricing yet, but don’t hesitate to contact us. [Less]

The Lokad facility where the first quantum forecaster prototype is hosted.Delivering more accurate forecasts has been the mission of Lokad since the very beginning. Today, after years of R&D efforts, we are extremely proud to announce the ... [More] immediate availability of new quantum forecasting technology that delivers unprecedented forecast accuracy well beyond the performance routinely achieve by statistical forecasting technologies. This technology leverages several key aspects of quantum mechanics, and in particular the Heisenberg reverse uncertain principle that states that there a fundamental limit to the imprecision of measurements made on the physical properties of particles such as position and momentum. From a demand forecasting viewpoint, it means that by shaping the course of particles to follow the patterns of observed in say, a time-series representing sales over time, the laws of physics guarantee a minimal amount of precision on the measurements to be made when the particles are observed continuing their trajectory beyond the point representing the “present”. Those measurements represent the physical projection of the time-series, that is, in layman terms, the actual demand forecast. Instead of relying on statistics, the quantum forecast leverages the law of physics themselves to produce the forecast. Schema of the Lokad quantum forecaster facility in Ufa, RussiaWhile the implications and benefits of quantum mechanics in terms of forecasting have been known to specialists for decade, the physical design of a quantum forecaster had remained an incredible challenge. A couple of years ago, Lokad opened a large scale facility in Ufa (Russia) to build such a device. It took us a long time to get it built, and an ever longer time to get it properly tuned. In particular, the launch was delayed because quantum interferences caused by the Large Hadron Collider operated by the CERN which proved to be troublesome. The addition of several extra Higgs boson detectors did finally solve the problem. At present time, Lokad is actively working on the miniaturization of the quantum forecaster. We don’t have a public pricing yet, but don’t hesitate to contact us. [Less]

A few days ago,  we were announcing a file hosting service now properly named BigFiles. Today, we have just released a web interface that let you upload and download your files directly from the web. FTP remains a preferable transfer mechanism for larger files or when there are many files involved.

A few days ago,  we were announcing a file hosting service now properly named BigFiles. Today, we have just released a web interface that let you upload and download your files directly from the web. FTP remains a preferable transfer mechanism for larger files or when there are many files involved.

Since December 2012, Salescast supports importing TSV files. However, until now, Salescast was expecting you to plug your own FTP server to retrieve those files. We felt this was an unnessary complication. Indeed, while there are a myriad of file ... [More] hosting services available on the web, we have found that most of them are simply not good at supporting business data transfers: annoying limits are encountered with: the maximal number of concurrent connections,  the maximal file size,   the maximal bandwidth,  ...  Thus, we decided to roll our own. We are proud to announce the immediate availaility of our FTP hosting service. Upload and download files from Lokad. The Express Plan comes with 1GB of free storage and 1GB of free bandwidth (per month). This service is compatible with Salescast and the other apps of Lokad. Technical nugget: In order to deliver maximum scalability and reliability, this service is built on top of Windows Azure - like all the other technologies developed at Lokad. The architecture schema below illustrates how we scale out the workload on multiple virtual machines. [Less]

Since December 2012, Salescast supports importing TSV files. However, until now, Salescast was expecting you to plug your own FTP server to retrieve those files. We felt this was an unnessary complication. Indeed, while there are a myriad of file ... [More] hosting services available on the web, we have found that most of them are simply not good at supporting business data transfers: annoying limits are encountered with: the maximal number of concurrent connections,  the maximal file size,   the maximal bandwidth,  ...  Thus, we decided to roll our own. We are proud to announce the immediate availaility of our FTP hosting service. Upload and download files from Lokad. The Express Plan comes with 1GB of free storage and 1GB of free bandwidth (per month). This service is compatible with Salescast and the other apps of Lokad. Technical nugget: In order to deliver maximum scalability and reliability, this service is built on top of Windows Azure - like all the other technologies developed at Lokad. The architecture schema below illustrates how we scale out the workload on multiple virtual machines. [Less]

In reply to the question from Stacy: Does your event store only serve one node type? Or does your event store serve any and all nodes? I did it in various ways, since different scenarios might require different deployment strategies. Here ... [More] are some cases that worked out. 1 event store for multiple subdomains, hosted within the same worker process. Event Store is hosted in the same worker process as well (with in-memory cache) and accessible via direct calls to application services from these subdomains. Worked nicely. 1 event store per node for our scalable FTP proxy for Azure project. Each node writes to it's own event store (hosting the engine). Event consumers (if there are any) join events together. Technically, in this case one could have one central event store, accessible by multiple nodes, but I didn't want to bother with complex deployment at this phase of the project. Plus, more dependent servers you have - higher risk of failure and problems. Multiple distinct applications, hosted in different nodes, with each of their own event stores. They can exchange information by sending commands or by pushing views with well-known schema to a well-known location. Event stores are kept private. So generally I treat event store as something private to the application. In single-node projects - one event store per application, in multi-node environments - one event store per node (or have multiple nodes share the same event store in case of some partitioning and load balancing). Obviously, this ratio does not involve various replication scenarios (e.g. master-slave), where replicas don't count towards the event store score (they still contain the same information). [Less]

Answering a question from the community: How do you handle security concern of sending aggregate id to the web client? What'd you do to ensure I can't, from the browser or another client, manually send aggregate id that belongs to another ... [More] client to either get some data about it or send some commands to mess things up? Each specific system scenario would lead to the specific design. If our specific scenario is: business logic is hosted on Application Server (e.g. hosted in Lokad.CQRS) which we control trust; client UI is hosted on Web server UI which we control and trust; Web server accesses application server (by sending commands and polling views) and renders HTML to user's browser. Then the solution to the security concerns problem is: We don't trust client browser anything (except from keeping unique token) we trust Web server UI to authenticate user (ensuring that he is who he claims to be). In this web App we will ensure that client sends only commands to the aggregates he is allowed to access (while checking commands as well). In app service we don't do any deep security checks and just carry out the commands. This scenario works well in simple situations where we have an app server and a few Web UI servers (alternatively with REST API servers), managed by the same team and hosted in the same controlled environment. If we have a different environment (e.g. application server can't trust web server), then a different separation of responsibilities might be needed. For example, we might need to perform authentication within the methods of Application service (checking that user is who he claims to be), while pushing authorisation down to method calls on an aggregate (checking that user can do what he attempts to do). In this scenario, authorisation might be encapsulated within an instance of domain service, passed down by application service to a method on aggregate. This service would have access to permission maps (or any other way of representing role/permission information), aggregate would call it's methods to find out if the specific user can perform requested actions on the requested resources. Naturally, in this case, Web UI must still ensure that we don't send illegal commands to the server. The difference from the first scenario is - we don't trust the web server to be diligent. These and other specifics of project environment, team organisation and trust can have a great impact on development process and product design. [Less]

The lead time is one of the two variables, along with the service level, that are essential to optimize inventory. Yet, calculating the correct lead time can be somewhat tricky because of start-of-day vs end-of-day variations, business days vs ... [More] calendar days, reordering delays, etc      The illustration shows a store reordering every 3 days with a supplier lead time of 4 days. The applicable lead time in this case is 7 days. Check out our new tutorial for lead time calculations. Stay tuned for more. [Less]