Really a quick question: I see chronicle Map 3X is moving some of the functionality to Engine product. However Engine itself relies on Map 2X. I am a bit confused how can I use them together? I assume I am missing something but not sure what exactly.
Yes - As you mention above, Currently Chronicle-Engine uses Chronicle-Map 2.
We have no plans ( in the near future at least ) to upgrade Chronicle-Engine to use Chronicle-Map 3. Although, this integration maybe done in the future especially if a paying client requires it.
There is no way to do tcp-replication with Chronicle-Map 3, so if you require tcp-replication, for the moment you will have to use Chronicle-Map 2 or Chronicle-Engine.
Related
I noticed that there are sometimes more than one function that produce the same output (or similar). In this case isDemo() and AccountInfoInteger( ACCOUNT_TRADE_MODE )
But the question is are the functions checked the same way? Do they both check the same types of information to verify demo status?
They both may be able to tell me if the active trading account is a Demo account, so when would you use one function over the other?
Are there any other functions that check for a demo status or could be used to check for demo status in MetaTrader Terminal 4, that I haven't found?
No,rather do not expect other functions to deliver the same thing.
The observed duality came out from a process of re-forming the historical grounds of the MQL4 language into something newer and closer the MQL5 domain.
When to use the one and when to use the other? Not any easy answer for such dilemma. Guess the old code ought work for at least some time forth, the newer syntax of the New-MQL4 has a bit lower probability of becoming unsupported in the compiler-phase ( if compared to the "old-&-good"-MQL4 )
I'm starting a new website, using CodeIgniter for the first time. In the views, there is PHP code written. I was thinking of completely separate the code from display, as I did few years ago using Smarty.
I found a template engine provided by CodeIgniter : http://ellislab.com/codeigniter/user-guide/libraries/parser.html
But inside of the page, I found this note :
Note: CodeIgniter does not require you to use this class since using pure PHP in your view pages lets them run a little faster. However, some developers prefer to use a template engine if they work with designers who they feel would find some confusion working with PHP.
So, I wanted some help to choose the right thing. Should I use pure PHP ? What would be the advantage of using a template engine like this one, when the coding style is already MVC ? Would it be better to use Smarty, that I already know a little ?
The website will need to be very secure AND very fast, a lot of AJAX will be used (I was thinking to install a websocket as well, but there is no link to the current question).
Thanks for your help !
If you require your application to be fast, then you've been quite inspired in choosing Codeigniter, as it's a very lightweight framework and it's going to solve most speed concerns quite easily, when caching isn't involved.
There's a saying that you shouldn't scale unless you need to, and I think that it applies very well here. Unless you're displaying megabytes of data, I don't see how choosing a templating engine might harm the overall speed of your application. In the event that it does happen, you can always have a look at caching some responses/various other bits of information or third party solutions (i.e. Gearman) which may be overkill for now.
If you want to learn something new, go with the Codeigniter templating library; if you need to develop something fast, use the tools that you know best. As a matter of preference, I love Twig, and there is a CI implementation for it, called Twiggy: http://edmundask.github.io/codeigniter-twiggy/
As for security, I'd say it's not as robust as an enterprise level framework, like Symfony or ZF2, which place higher emphasis on that. They are more complete packages in themselves, and with caching, they perform super-fast, but they come with a higher learning curve.
Update: What I meant by the the idea that unless you're displaying huge amounts of data you shouldn't consider the speed of templating engines is that there will be a negligible effect on your page rendering speed. Don't imagine that it's something that a user would ever notice, as the order of 0.0x in execution time isn't noticeable. Take a look here for a comparison between SMARTY and Twig: http://umumble.com/blogs/php/249/
0.058 seconds of execution time for Smarty vs. 0.083 seconds of execution time for Twig. Templating engines always carry an overhead, their facility is that they make development easier, and it helps out when working with designers.
If you want to go with a templating engine, I suggest Twig. http://twig.sensiolabs.org/
We have an old (written in CakePHP 1.1!) application that has started groaning under the weight of its responsibilities, so we're giving it an overhaul with the help of some consultants.
One of the "quick wins" that they have identified: some pages are experiencing not-insignificant slowdown due to multiple calls to $html->url. As for whatever reason we're not currently using routing, and even in the future the necessity for reverse routing isn't likely to come into play, use of $html->url could just be creating overhead for the sake of it here. Some questions that arise in my mind in any case:
(1) Is it better to do things "the Cake way" where possible even if this is slower? Are there other advantages to using the HTML helper for links that might not have been considered.
(2) We are planning to upgrade to a much more up-to-date version of Cake, possibly all the way to 2.0, at some point. Is it possible that the current slowness of using the HTML helper is more to do with being in Cake 1.1 than an inherently bad design decision?
Just interested in people's opinions generally on this subject: is it definitely right for us to strip out laborious uses of the HTML helper or not?
An upgrade to CakePHP 2.0 will definitely yield a speed improvement. Beware however, the upgrade path from 1.1 to 2.0 is not smooth. Expect to do a lot of manual editing.
As to the multiple calls to $html->ur(), you might find this useful:
http://debuggable.com/posts/how-to-save-half-a-second-on-every-request-of-your-cakephp-app:49a69610-8648-4d65-815d-754c4834cda3
I would rather consider:
Rewriting HtmlHelper::url(). It is very surprising that such a simple function has a performance impact. Consider using a version from a future release.
Cache the views (or the elements, or extract these into elements, then cache) so they are not triggered in each request.
I have a product that gathers and displays measurements of all kinds (won't go into it). The display portion is, as one would expect, a database + website built on top of it (with Symfony).
However, we'll probably be creating an API to expose the data to third-parties as well.
Now, we either have the choice of building both the website and the API on top of the database, or just build the API on top, and have the website implement the API.
I would greatly prefer the latter, since otherwise I'll have to adapt both model layers for the API and the website every time the schema changes (which can be a few times).
If I have the latter I obviously have the advantage of only adapting the API model. If the API contract stays the same, the website wouldn't need adapting.
However, obviously there is a downside in performance.
With website <-> database, vs website <-> API <-> database, the first will obviously be the fastest.
My question is: what is your opinion on this trade-off?
I'm hoping the performance can be almost evened out, since all the machines will be on the same LAN + there will be caching. If that's the case, the ease of development would certainly make my life easier :-)
Looking forward to your opinions and experience!
If there was ever a case of premature optimization, this is it! You're not going to know the answer without more information, and I suspect very much that the performance differences between the two will be so negligible as to be irrelevant in your domain.
The best approach, IMO, is to spike on a few of your models using both approaches and see where that gets you.
No better way to make sure your API is going to be usable by others than to use it yourself. I would go website -> API -> database. Write it once, you can always tune it and "cheat" later if you have too.
Many modern websites use JavaScript (AJAX etc) and then make service calls to an API. If you took that approach you would simply have a carefully designed, reusable API layer in front of your DB.
I find that there's little or no extra effort here, and I'm sceptical that you'll incur noticable performance penalties.
I'm a little hesistant against to use it because I believe there can be some issues with it, but I don't really know it before I've tried it. Or is it good enough to use it or should I do plain sql statements? Does anyone know?
It has it's advantages and disadvantages. One advantage is that all queries are automatically formatted, escaped, and optimized. This is a big plus on the security side because we all forget to do everything that can be done to protect ourselves sometimes. Active Record doesn't forget.
One disadvantage is that it sometimes is difficult to construct complex queries with it but that's easily taken care of by just running your own. All in all i would highly recommend using Active Record. We have been using it for our enterprise level application for the last 1.5+ years and it hasn't failed us yet.