Hi I have been asked by my employer to document how our FIX Spec will map to another venues FiX Spec.
This will require hard work as it involves going through each message and seeing how it is different to ours. What is the best way of documenting this? Is there any software that will make this task easier?
If you are using QuickFIX I would say to have your custom FIX dictionary in the XML format, you can use the default one for FIX 4.2, 4.4, etc and change accordingly to your needs
http://sourceforge.net/p/quickfixj/code/1113/tree/trunk/core/src/main/resources/
Then you can generate Java code for example with QuickFIX/J Code Generation and write unit tests to check if you still comply with your FIX Spec
http://www.quickfixj.org/quickfixj/usermanual/1.5.3/usage/codegen.html
Related
I've been a heavy Windsor users for the last several years. Prior to the Fluent Registration API, I would toggle between Xml Registration and huge piles of AddComponent() code. We've been happily using the Fluent Registration API and Installers specifically for quite some time now. I've gotten the impression from various writings like this:
http://docs.castleproject.org/Windsor.XML-Registration-Reference.ashx
That the Xml Registration approach has fallen out of favor and it wouldn't surprise me if it were marked for deprecation at some point in the near future.
Now, for my question: The Fluent Registration API and Installers work swimmingly for auto-wiring scenarios (i.e. when I want Windsor to just figure out how to construct my object graphs). Auto-wiring is the vast majority of IoC use cases out there, but what about when auto-wiring isn't possible? In other words I have multiple implementations of a service and I need to tell Windsor how to construct parts of my object graph. I've done this many times with the Xml Registration approach, but is there a more preferred approach these days? I'm hesitant to go the Xml Registration approach as its future seems uncertain, but I don't know how else to accomplish this with Windsor.
My uses cases are:
System needs to be able to swap implementations at QA-test (i.e.
credit checks and fraud detection processing where we want to test
without a dependency on a credit bureau API)
Provider patterns in our
system where we need to conditionally turn on and off different
implementations at deploy-time.
This all seems very well suited for IoC and we have all the building blocks in place, but want to make sure I'm taking the most future-proof approach with Windsor.
UPDATE:
While I like the feature toggle approach, I recently discovered a Windsor feature that is very useful on this front - Fallback Components. I'm leaving this edit here for anyone that might stumbled across this later.
Configuring your DI container completely through XML is error prone, verbose, and just too painful. The XML configuration possibilities are always a subset of what you can do with code based configuration; code is always more expressive.
Sometimes though your DI configuration depends on deploy-time configurations, but since the number of knobs you need are often fairly small, using a configuration flag is often a much better approach than polluting your configuration file with fully qualified type names.
Or let me put it differently, when you have large amounts of your DI configuration placed in your configuration file because your might want to change them at deploy time, please think again. Many of the changes need testing (by a developer) anyway, so there is no way you want someone from your operations team to fiddle around with that. And when you need a developer to look at it and verify it, what's the advantage of not having to recompile the project? Is this actually any quicker? A developer would still have to start the application anyway.
It is a false sense of flexibility and in fact a poor interface design (xml is the interface for your maintenance and operations department). BTW, are you the person that needs to document how the configuration file should be changed?
Instead of describing the list of fully qualified type names that are valid somewhere in the middle of the xml file, wouldn't it be much easier of all you have to write is "place 'false' in this field to disable ..."?
Here is an example of how to use a configuration switch:
bool detectFraught =
ConfigurationManager.AppSettings["DetectFraud"] != "false";
container.Register(
Component.For(typeof(IFraughtDetector)).ImplementedBy(
detectFraught ? typeof(RealDectector) : typeof(FakeDetector));
See how the configuration switch is now simply a boolean flag. This makes the configuration file much more maintainable, since the configuration is now a simple boolean switch instead of a complete type name (that can be misspelled).
Of course doing the ["DetectFraud"] != "false" isn't that nice by itself, but this can simply be solved by creating a strongly-typed configuration helper.
This answer might help as well. Allows you to dynamically, at runtime, provide an implementation. Though, sounds like you don't need it that dynamically and it's a little less obvious what's going on.
There are no plans to obsolete or remove the XML config support in Windsor.
Yes, you are right, it isn't a preferred approach due to its numerous drawbacks.
Anything you can do in XML can be done in code (note that inverse is not true).
Also keep in mind XML is not all-or-nothing. There are many ways to achieve the scenarios you gave as examples without resorting to registration in XML.
Feature toggles
Conditional compilation
if/else in your installer based on a appSettings flag
others...
I've used each of them in different projects in the past.
We are planing to generate JBehave stories dynamically by entering the when then commands (?) in a simple web form. I am not sure, if I like that idea.
I mean, I could programatically save the .story file before starting the test and point to this file in an overwritten StoryPathResolver.resolve method.
But, do you think that this would make a lot sense?
Thanks
I'm not sure if I understood your planned feature, but based on my assumptions *), I say: no, it does not make sense for the following reasons.
My assumption on this here is that you want to perform (test) the system on-the-fly and/or you don't know how beforehand what should be tested.
But either way, whatever is typed in wont be reproducible for later regression tests nor any other typical benefit that comes with automated tests would apply, first and foremost: speed.
Instead of implementing such a framework that would present you the options available at each step as well as the stop-and-go system that would be needed, it would be way better to optimize the path of writing the .story files and inject them into a running system. This way the writer still can take any time to specify the examples as well as having them reproducible from the start.
*) Should I be wrong, please rephrase your question. There are a few other questions in your first post that I could deduct.
So, I've been trying to clean up my code and learn things that I should always do...well of course server-side validation is one of those things that I should always do. However, what happens when I have this huge form? I really would like to have a generic function that allows me to pass the data type and field name. Is there a secure way to do this in Coldfusion?
I've been looking into doing this for a while, but I've come to dead ends and can't find any info on doing something like this on the web. It seems like Coldfusion does not offer this ability.
However, I think it would be cool if there was a way to specify an attribute in your input tags that had the data type of the field. Then, it would be uber nice if Coldfusion stuck it into a struct for you with your field names.
Is there anyway to accomplish this or can someone elaborate on the most efficient way to do server-side validation?
That would be great if CF had something like that! Good news, it does, for years now! :)
What you're looking for is cfinput (and cfform) tag. This tag includes the validation specifics right in the tag like you're wanting (great minds think alike, right?). You can specify the validation, the error message, if it should validate client or server side - all kinds of neat tricks.
Check here for implementation - it's quite easy to use:
http://livedocs.adobe.com/coldfusion/8/htmldocs/help.html?content=Tags_i_07.html
Be warned that a lot of code diva's hate cfform / cfinput. In reality, there is nothing wrong with them when implemented correctly. It can be abused and it won't fit for every solution, but that is true of everything in the toolbox. By and large, for most form input and validation situations it works great.
If you hate that idea, another is to use the built in type attribute of cfparam and catch your errors.
For example, at the top of your form processing page, you can :
<cfparam name="form.cardNumber" type="creditcard">
When this is reached, if the value in that variable is not of that type, it will throw an exception that you can catch. This keeps you from having to write the if() and pattern matching. Additionally, if there isn't a type built in, you can specify a regular expression for pattern matching.
Here's some more information and the types supported:
http://livedocs.adobe.com/coldfusion/8/htmldocs/help.html?content=Tags_p-q_01.html
Let me know what you think!
I would encourage you to look at possibly using a ColdFusion framework like CFWheels (or ColdBox) which has a lot of this type of functionality already built in to make development a TON easier. Using CFWheels has been one of the best decisions I've made as a developer and my development skills have grown significantly over the past year. There's some great screencasts online to get started. http://cfwheels.org/screencasts
I have a service that receives an object containing all the data needed to build a newsletter. I need to be able to generate the email using different templates.
I don't want to involve the whole ASP.NET stack for that, so I want a separate templating engine.
Reading a lot of opinions, I have found that XSLT was not getting very much love when it comes to templating engines. Why?
SparkViewEngine is a "new cool toy", but it seems mature enough considering the number of projects that have been built with it. What do you think?
Did you used those 2 engines? in which situation, and what strength/pain did you enjoy/endure
XSLT is much more verbose, especially when it comes to tricks like conditional attributes. I used it a lot (even to generate C#/C++ source code) but I don't remember that time to be a joy. Spark is.
I used a Spark template to generate an email on my last project, it was a fairly straight forward experience.
As you mentioned you have an object containing all the data needed to build a newsletter. To use XSLT wouldn't you need to serialize to to XML first? Using Spark skips the serialization step and gets you directly to the output you want, and as queen3 mentioned, creating conditional attributes is quite easy.
In case you need it, there's a post on how to use Spark as a general purpose templating engine here.
Also if you have to work with any graphics designers it may be easier to take an HTML mockup and turn it into a spark template than it would be taking an HTML mockup and turning into an XSLT.
I've been trying to find a good form of RPC to standardize on, but so far I've ran into a ton of walls and was wondering what the stackoverflow communities view was.
My ideal RPC would provide the following:
Somewhat wide support in other languages, in that people shouldn't have to write a custom stack to use our server
Input validation
Ideally, some way to turn the above input validation into some sort of automated documentation to distribute
Clean and maintainable code
I am a fan of the catalyst framework and would prefer to stick to it, but if there is a clearly better alternative for RPC servers I'd be open to that as well.
So far I have looked at the following:
Catalyst::Controller::SOAP
Doesn't appear to support returning of complex data structures, only string('literals'). I could probably serialize data on top of that, but that seems very hacky. It also lets you return a pre-formed XML object, but I couldn't get that to work and it looks like you'd need to re-create a lot of SOAP data structure for it to work.
I do like the idea of WSDLs, but the complexity of the overall spec also makes me wonder how well support for communicating with other languages will be.
Custom POSTing XML based controller
We tried to roll our own by hand in a similar way to how we've seen two other projects do it recently where there is a dispatch url that you post XML to. This lets you have XSD validation/documentation, but required creating a lot more code than we want to maintain at this point.
Catalyst::Plugin::Server::XMLRPC
Gave a warning about using a deprecated method that will be removed in a future version of Catalyst.
No input validation or doc creation, but otherwise the best I've found
JSONRPC
Looks pretty similar to XMLRPC only the module is actually updated. I'll probably go with this next unless someone suggests something better
There also appears to be two different modules for catalyst that do JSONRPC
I realize that REST isn't pure RPC (only a subset), but...
I would recommend the Catalyst::Controller::REST and Catalyst::Action::REST modules. They're frequently updated and the documentation is fairly good. There is also a good (but rather dated) example of using Catalyst::Controller::Rest in the 2006 Catalyst Advent calendar titled Day 9 - Web Services with Catalyst::Action::REST.
FWIW, Catalyst::Controller::SOAP does support returning complex data. Take a look at the documentation http://search.cpan.org/~druoso/Catalyst-Controller-SOAP-1.23/lib/Catalyst/Controller/SOAP.pm, which will show you that you can use a WSDL to describe your service. Also, see http://daniel.ruoso.com/categoria/perl/soap-today.html.en for a more detailed step-by-step process.