I need to implement persistent queues for a new solution and have been looking at Rhino Queues. Unfortunately either there is not much documentation available or I am just not looking in the right spots.
Can I simply add the Rhino.Queues NuGet package to my project and make use of the queues in my application? If so, where can I find better documentation that explains the proper use of the queues? For instance, when running in-process, what do I specify for an endpoint?
Related
Suppose you have a Schema that is used in a UI-App (e.g. Vue), a Node.js or Springboot Server and has to validate against Databases (e.g. SQL, mongoDB,...), and maybe some Micro-services running on whatever.
How and where do I manage a this JSON-Schema, so that if I have to change the schema for whatever Reason, that every architectural component can handle the new JSON-Schema(s).
Otherwise I need to update the Schema in up to 10 projects so none is incompatible.
Is it really as simple as having a git project full with just JSON-Schemas or do I need specific loaders for each language/environment?
Are there best practices that I am unaware of?
PS: I don't really think I need the automatically synchronized on runtime, so don't really think I need another Microservice to achieve that.
That being said, if a Microservice is the best way to go, then getting a Microservice it is.
If you keep them in a git project, how do you load them? Clone the project each time the app starts? It may work, but I would go with a more flexible approach that should take too much effort to be done:
Build a JSON schema repository accessible via a REST API
When the app starts, it makes a request to grab the schema (latest, or a specific version)
That way you get an uniform (and scalable) way of playing with the schemas. Even if you think about a hot-reload sometime in the future, you can leverage this approach to do that.
Here is an old project in this direction, you may give it a shot to see if it works (or for some inspiration, at least)
12-Factor Apps suggest that you configure your application using environment variables. So far, so good. I can easily imagine that this is a good way to do it if you need to set a connection string, e.g.
But what if you have more complex configuration with lots and lots of values? I for sure do not want to have 50+ environment variables, do I?
How could I solve this, and still be compliant to the idea of 12-Factor Apps?
From a quick read of the configure link you provided, I agree with the author's claim that there is a widespread problem, but I am not convinced that their proposed solution is going to always be best. Like you, I don't relish the idea of having to define dozens of environment variables to configure an application. So here are some alternative ideas.
First, read Chapter 2 of the Config4* Getting Started Guide (disclaimer: I am the main author of that software). In particular, notice that its support for what I call adaptive configuration can go a long way towards addressing the concern that you ask about. Is Config4* the ultimate solution? Possibly not, but I think it is a good step in the right direction.
Second, the chances are that whatever application you are developing/maintaining has already settled on a particular configuration technology, such as XML files or Java property files, and it won't be feasible to migrate to using Config4*. This raises the question: is there anything you can do to avoid having a proliferation of, say, XML-based configuration files when you have multiple environments (such as dev, UAT, staging and production) in which the application will be deployed? I have outlined an approach for dealing with this issue in another StackOverflow article.
We've recently made the decision to move away from .NET and SQL on our backend and rather implement a nodejs solution with either MySQL or postgreSQL. My server guys are putting a standard restful API in place using sequelize as the orm middleware.
Does anyone have any experience in implementing breeze in such a scenario? I understand that I'll have to define the client metadata by hand, but once this is done, do I lose any of the functionality that breeze offers in a typical .NET implementation using the EFContextProvider and server generated metadata? Also, can I use a standard restful API call, or is additional configuration required on the server side?
I think this is an exciting approach.
Breeze does not (yet) offer node-ware for this scenario. You'll have to decide what features of the ContextProvider you like and port them to node. I don't think that has to be super difficult and we'd love to help where we can. This would be a terrific contribution to the community.
What you are looking for in "a standard restful API" will determine many of your design decisions. Do you want to support OData style queries so that client code can compose queries? Or will you take a different approach?
Do you intend to have separate PUT, POST, MERGE, and DELETE calls for each resource? Or will you have some notion of "change-sets" for combining multiple save operations in a single transaction? Something in between?
Breeze favors a change-set approach out of the box. OTOH, if you want to go "straight" REST, there are RESTy Breeze dataservice adapters that suit that style with more on the way.
You can could learn a lot about the mechanics of query and change-set saves in Node by looking at how we handled them in the "breeze-mongodb" npm module referenced in the Zza sample for Node + Mongo.
Take a look at our MongoDB example. This is the breeze client talking to a Node/MongoDB backend. It's not exactly what you are looking for but it does should how one can build a Node backend to talk to Breeze. Also feel free to contact breeze#ideablade.com about consulting in the event that you need help with or want us to implement such a backend.
As a note there are now several samples on Github using node server / breeze / [mysql|postgresql|etc...]
Docs explaining -
http://breeze.github.io/doc-node-sequelize/
Related repositories -
https://github.com/Breeze/breeze.server.node
We have a group of developers moving from C++ to C# and WinRT. We used D'Oxygen as part of our C++ developer builds, and I'd like to continue to have document generation as part of the developer build in C#/WinRT.
It's easy to turn on XML Doc generation, and I believe that will provide warnings for malformed tags, but without actual HTML output, I think our developers will be missing valuable feedback.
Looks like NDoc is now defunct, and I took a quick look at Sandcastle, but found it rather complex. Ideally, I'm looking for something that doesn't unduly burden developers, or require them to remember extra steps as they edit, build, test, and commit. In other words, the best solution would be something that "just happens", like a post-build step, and doesn't add significantly to each developer's build time.
If anyone has had some experience doing this in C#/WinRT, I'd sure like some advice.
Thanks in advance!
Get Sandcastle Help File Builder.
Create a help project for your library in the Visual Studio solution.
Remove Build check mark from Debug solution configuration to build the documentation project only in Release configurations, since Debug is most often used during development. For release build testing or performance testing you can either create another solution configuration or simply switch the option back and forth.
Build the documentation once
Include the documentation file in the solution so it shows up in the Pending Changes window when the file changes.
Kindly ask your developers to build with the release configuration that updates the documentation before check-in or use any other policy to require updating the documentation.
I don't think it makes sense to build the documentation all the time, but it helps to make it easy to do so that when you actually need an updated version - you can build it really quickly.
You can also make sure to use FXCop or StyleCop (forgot which) and configure it to treat missing XML documentation warnings as errors - at least in release builds. Doing it for debug configurations might slow down development and make changes difficult since developers often want to try things out before committing to a final implementation worth documenting.
EDIT*
Sandcastle provides various output formats as shown in the project properties:
I would like to mention ForgeDoc (of which I'm the developer), it could be what you are looking for. It is designed to be fast and simple, and it generates proper MSDN-like HTML output. It also has a command-line interface so you can just call it from a post-build event command in Visual Studio.
I think you should give it a try, as I would really like to hear about your thoughts.
Inside a Java project I use Google Protocol Buffers (GPB) for serializing my objects. I can use the same .proto files in auxiliary Python code, which is great. Now I'm adding a Flex client to the whole thing and I'd like to use the same .proto files once more.
It seems there's a couple of projects out there which compile .proto files to Actionscript. From a few glances at the projects' homepages, it seems to me that protobuf-actionscript3 is actually the most advanced and most "alive" of these projects.
Has anybody had practical experience with GPB to AS3 compilers and which one(s) can you recommend (or recommend against)?
If you're sure you want to use GPB, then protobuf-actionscript3 is your best option. It builds on the semi-successful protocol-buffers-actionscript project: http://code.google.com/p/protocol-buffers-actionscript/
If you're open to looking at other formats, there's always Adobe's own AMF3. It seems to have a good amount of community support behind it.
The only choice now is https://code.google.com/p/protoc-gen-as3/. All the other Protobuf/AS3 projects are out-of-date, and lack of features.