Development of a FIX engine - trading

I am new in the FIX and have requirement to develop a small FIX engine to communicate trading system. As I know there are plenty of FIX engine available but here requirement is to develop it.
Could anyone provide me the reference on any open source or any good article to start it?

For C++ use quickfix
Java use QuickfixJ
For .NET use VersaFix
To refer to Fix message constructions.
Both the libraries(Quickfix) have the same nomenclature as mentioned in the FIX protocol standards. But they are little buggy here and there, but you can rectify them in your source code. I have used both of the libraries in a commercial project and say so after seeing the libraries work. But the code is quite simple and they have an online reference manual to work with.
But developing your own library will be a big task for only one developer, if you have a team it can be much easier. Remember other than parsing you have to incorporate network communications, configuration on how to run it and threading structures also.

Developing your own FIX engine is not easy, specially if you will be dealing with FIX session level details yourself. Synchronizing sequences through ResendRequest, GapFill and SequenceReset is not easy and it would be nice if you can just use a FIX engine that is already doing that for you.
Another problem with the FIX protocol is REPEATING GROUPS. It is not easy to parse them quickly as it requires recursion or alternatively a complex iterative implementation.
Moreover, most Java FIX engines produce a lot of garbage when they are parsing the message, which increases variance and latency due to GC overhead.
Lastly, an intuitive API design is crucial to accelerate FIX development. If you want a good example of a clean API, you can check CoralFIX.
Disclaimer: I am one of the developers of CoralFIX.

You certainly want to look at QuickFix.

Related

Microsoft Edge - the best way/utility to reverse engineer extensions assembly code

I need to understand how Microsoft Edge/Firefox/Chrome works for extension installation.
Firefox and Chrome are easy to work with, as they are open source, honor and praise for them! :)
But there are problems with Microsoft Edge
I am using WinDbg - it's pretty common and allows to debug internals.
Particularly, a very interesting part for me what happens on the application's exit, start and turning on and off our non-store custom extension.
Problem: there is too much code and it's not easy to find out that particular code is required to be debugged.
Before M.E. will move to chromium we have to do this kind of reverse engineering.
Thank you, guys! :)
UPD: I'am thinking about adding C++ tag, but don't know whether it's a good idea.
UPD 2:
I don't need utilities, software recommendations, rather techniques that allow understanding vast amount of assembly code.

How can I consume iOS libraries from MonoTouch/Xamarin.iOS?

I'm trying to find a straightforward way to consume arbitrary iOS libraries from MonoTouch. At the moment, I need this calendar functionality, but the question applies to any such component.
I've read the Xamarin article on creating iOS bindings, but the process of building these bindings looks so complex (and tedious and likely error prone) that I think it would actually be easier for me to re-implement the given functionality in C# from scratch than it would to go through this process. Creating these bindings would require a deep dive into ObjectiveC, and I'm using Xamarin precisely so I don't have to do that.
As it stands, I am torn because I really want the ability to access some iOS libs, but don't have the time to master this process enough to create these bindings. Is there any other way to access these libraries?
(I wonder if there is or could be any sort of automated binding generator? It seems to me that 95% of the work is boilerplate translation of ObjectiveC headers to C# idioms, and an automated tool could do this, and then the final tweaking could be done by hand.)
You can:
Consume the ones that are already bound: you can find many on github, in particular in monotouch-bindings, and in the (just announced) Xamarin's Components Store;
Bind them yourself. That does require some Objective-C knowledge. Some tools/scripts exists but, in the end, the manual by hand editing is where the Objective-C knowledge is needed. There are general unit test (e.g. for Touch.Unit) that you can re-use that will dramatically reduce the number of bugs in them (blog post will be coming up soon to describe them in details).
Convert (or write from scratch) some into C# components;

EventMachine vs Node.js

I'm going to develop a collaborative site, and one of the features will be collaborative editing with realtime changes. i.e. when two or more users are editing the same doc, they can see each other changes as soon as they happen.
I have some experience with Ruby on Rails, so I was thinking about using EventMachine, but with all this hype around Node.js, I am know considering using it instead. So, what would be the main benefits of using Node.js instead of EventMachine?
tl;dr
What are the main differences between EventMachine and Node.js (besides the language)?
EventMachine has nothing to do with Rails apart from them both being written in the same language. You can get EventMachine as bare as Node.js; all you have to do is not add libraries to your project. In my experience the EventMachine libraries (like em-http) are much nicer than anything for Node. And you can use fibers instead of callbacks to avoid callback hell. Complete exception handling is pretty much impossible in Node because of all the callbacks. Plus Ruby is a nicer, more complete language than Javascript.
I tend towards the "use what you know" (even if it's a heavier architecture). Because of that, I don't see it being quite as simple as "EventMachine vs NodeJS." Mainly, the difference can be summarized as this:
NodeJS is a framework/language that was written to handle event based programming in JavaScript. That is its driving force. It's not an after thought, or a third party mechanism. It's baked right in to the language. You create callbacks/events because that's how the language is built. It's not a third party plug in, and doesn't alter your workflow.
EventMachine is a gem in Ruby that gives developers access to some of the goodness of the event based programming model. It's heavily used and well tested, but not baked directly in to the language. Both are locked to one CPU, but with event programming at Nodes core, it still has a leg up. Ruby wasn't written with concurrency in mind.
That said, technical problems can be overcome. The more important questions (from my view) that should guide your decision are these:
What will your production environment look like? Do you have complete control over the server? Can you host it however you want? Or will it be on a shared system to start with, and then you have to expand on that?
Do all the developers on your team have the ability to learn a new language very fast? How fast will they be able to understand an event-based language like JavaScript for the middle tier?
Do you need all of the architecture that Rails gives you (full Testing framework, scaffolding, models, controllers, etc)? Or is that overkill?
There are quite a few technical differences between the two. One is a language, one is a framework. Really, how heavy of a stack you want to run? How much learning will your developers have to do? Do you want a full stack the gives you a lot of niceties, that you may not use, or do you want a bare bones set up that runs extremely fast and concurrent, even though you may have to write extra boiler plate code and learn a new lanugage?
While Rails is not as heavy as some web application architectures, you're still going to need more processor power than you would to handle a similar amount of throughput in NodeJS. Assuming quality code for both systems. Bad code written on either stack is going to prevent the stack from shining. It really comes down to- Do you really want to learn a whole new way of doing things, or utilize your current understanding of Ruby to get things off the ground fast?
I know it's not really a definitive answer, but I hope this helps guide you to a decision!
One thing worth mentioning is the production story. EM, like most Rack stuff, has plenty of testing and monitoring tools available that are well tested, whereas Node.js falls well short in this respect.
At the time of writing, it seems almost impossible to get clear metrics from Node to answer questions like 'Do I need to scale'. There are options starting to form out there from the likes of Joyent, and always the roll-your-own argument, but nothing anywhere near tools such as NewRelic.
Node.js is very good from a performance / configurability point of view, but personally I wouldn't host it in production just yet.
Node.js
You get far better control low level control over what's going in. You can include general libraries to build on top of node.js to tweak your level of abstraction to your own liking. For example you can use connect or express depending on whether you want a view engine written for you.
You can use socket.io or now depending on how much you want your client-server connection abstracted. You can opt to include any of numerous MVC libraries or write your own.
Event-Machine
An asynchronous IO library just like node.js
It comes down to a Ruby vs JavaScript preference, how much flexibility you want with abstractions or lack of abstractions and whether you want to use node as your actual web server.
a detailed view at confusion has already been proposed... just a personal view
[] node.js will be better, if you are ready to learn and experiment more than you think because:
it's thread mechanism is awesome (inspired from that of 'erlang')
you can build a purpose specific server (easily) which will be real productive

What technology stack is Second Life built on?

For example, are they using Java/Struts? Or ASP.NET? Or PHP? Or some combination of technologies?
Not sure how public they are about their infrastructure, but it would be very interesting to know what they use.
Not sure if this is what you are looking for, but see here: http://en.wikipedia.org/wiki/Second_Life#Technology
As is often the case with such questions, High Scalability has an overview of the Second Life architecture, plus links to presentations by SL staff and other resources.
I will take a wild guess, a combination of scripts running on a server written in C++.
While this is an antique question, I'm surprised that no one mentioned OpenSimulator or some other Sim application. OpenSimulator will allow you to run your own Second Life clone on your own hardware and with one of the many SL viewers that are out there, you could just connect to your own virtual world. And this World would be very similar to SecondLife, including it's scripting language!
OpenSimulator is written in C# back in 2007 using the Second Life Protocol to be very identical, although they don't strive for complete compatibility.
The Firestorm Viewer is also open source as Linden Labs once published the source code of their viewer using an LGPL license. But the Firestorm team doesn't make access to the source code easy to find. (It is here!) You will need to know C++ to understand the code.
So, Second Life is made from three parts: Server, client and a special protocol that goes in-between. As Second Life is old, it also uses some older techniques and protocols as developers generally don't fix things that aren't broken. Then again, this question is also old and I'm not even sure if anyone is still interested in Second Life.
Still, if someone is still interested then this gives some nice additional information.

How is Spring.Net making my life easier?

"Spring.NET is an open source application framework that makes building enterprise .NET applications easier."
Springframework
They say that Spring makes .Net development easier. Then I see the manual which is long as anything.
Chapter 5. The IoC container
And then I see some mysterious stack trace errors when I run a project that has Spring. How is Spring making my life easier, when everything is so hard?
Edit: The errors come when I run the project, not when I compile like I first wrote. I understand that Enterprise applications need more complex frameworks than normal applications. But they shouldn't be complicated even in that case. I mean, if I want to write some logic, I shouldn't need to go through lots of other stuff.
Edit: I don't have a choice but use Spring, if I start using an existing project that has it.
Note that it says it makes enterprise .net applications easier. Enterprise applications are not really the same as normal applications. They are very large scale applications, requiring designing around massive scalability, portability and extremely flexible configuration. Frameworks that simplify this process are still going to be difficult to use, but are less difficult and more reliable than doing all of that work from scratch.
I would be dubious of using an enterprise framework in a 'normal' project though, as it is most likely extremely overengineered for non-enterprise requirements and could end up being more difficult than coding from scratch in that circumstance.
It provides an IoC container. Yes, using that to its full requires reading quite a lot. The same is true of almost any powerful tool. If you're going to use LINQ, that needs some study too - does that make LINQ useless in your view?
It provides useful utility classes for various things. Often these are things you might roll yourself in other circumstances.
Now, as for why you're getting mysterious stack trace errors when compiling a project which uses Spring.NET... that sounds very odd. We'd need to hear more about the errors to know what's going on.
If you don't understand, you might ought not use spring.....
But Spring.NET is a good framework. It is more than IoC, alot more....
If you don't understand dependency injection/IOC or Aspect Oriented Concepts, spring may not do too much for you and you might as well stick to service locator type things and explicit try/catch blocks all over your code....
I agree with you that it has some learning curve, but that alone should not discourage anybody from learning this really awesome tool.

Resources