I'm a casual developer and typically use VB.Net when writing solutions, as its what I'm most familiar with. Though I aim to learn other languages in the future, such as C#, its very much on the back-burner and so here we are.
One of my current projects would benefit greatly from a service-bus architecture, so I have been researching potential options. Some of the more obvious choices, such as Azure Service Bus, are out of the question, as my application will not have access to the public internet once operational. Looking in to options that could be run within a local site I've stumbled across both nServiceBus & MassTransit as front runners.
My current stumbling block is that all the documentation and sample code seems to be written for C#. My question would be if the frameworks require programming to take place in C# exclusively, or whether I can utilise another .NET language (such as VB) instead. If this is indeed possible, I wonder if anyone could point me in the direction of some sample code? Of course I can gradually reverse engineer the C# if necessary, once I know if VB development is even possible (or practical).
Thanks,
Chris.
Related
My company is planning to build a simulation tool for processing (beverage) and we're currently looking at a half-baked system written in Xojo. I had personally never heard of this language and would appreciate it if anyone could give a quick assessment.
We have no in-house Xojo competence at all and are of course reluctant to bring in a system that would require a big investment in know-how for just one system.
So, we're now looking at our options: Port it to a language we're good at (C# or Java) or continue development in Xojo while building internal skills for the language.
So, what are the big pro's and con's with Xojo?
Cheers
Xojo has been around since the late 1990s, then named RealBasic. Its strength lies in its ability to make native looking and behaving apps for many platforms, mainly OS X but also Win and even Linux. The dev community is fairly small, though. But the company managed to stay in business all this time and isn't looking to end it any time soon.
The language is fairly simple and easy to learn, using long known concepts (its design was based on Visual Basic).
Knowing Java, it should be easy to grasp the language. The bigger hurdle is probably getting familiar with its libary. Many things are much simpler to accomplish in Xojo vs Java, though.
Call me lazy, but that's what I like about Xojo. I also program ObjC in Xcode, but for those little tools that just need to work quickly, Xojo is superior for whipping out a program quickly that that has a decent UI and works on many platforms with little to no tweaks.
If you need x-platform support, give it a try, for sure. If you only need the app to run on a single platform, and if you have skills with other dev systems, I'd advise against starting out with Xojo, to avoid the risks you get when going with such a small company that's offering closed-source software.
In your particular case where you have already a half-working solution, I suggest you take a few days to familiarize yourself to get a feeling for it (you can use Xojo for free as long as you don't build standalone apps with it). It's overall fairly stable and I'm still using a 3-year old version most of the time to develop and build my apps. So, even if Xojo should go out of business suddenly, I'd not be too worried. As long as you stick with the simple functionality (e.g. not use unique features such as XojoScript), you can still convert the app to another language later, but there's also a fair chance you never have to.
If you are looking for someone to take a look at your Xojo project I'd recommend posting on the Xojo Find A Developer page at http://www.xojo.com/support/consultants.php where all Pro developers get it. The consultants that want to talk to you about it will then contact you. (Full disclosure: we, BKeeney Software, are on the list and would be happy to help you figure it all out).
This topic may look like it has been discussed already but I have few more things to say and ask.
The obvious question is; I want to know what AOP library shall I go for a .NET 4.0 enterprise application? As per the post What Aspect-Oriented Programming (AOP) libraries for .NET are still actively developed, one should choose PostSharp or Spring.NET or Microsoft's Policy Injection Application Block. But there are problem with each one.
PostSharp: This is best but not open. I need one whose source is open.
Spring.NET: This is too heavy and has limitations like it can intercept only those classes that is not static, must be non-sealed, properties and methods must be virtual, etc...
Microsoft's Policy Injection Application Block: As per the post Policy Injection Application Block, this is a legacy component now and may stop being supported by MS and since it is implemented through the Unity interception mechanism hence it has same limitation as that of Spring.NET (Alternatives to PostSharp)
I came across the post Aspect Oriented Programming: learn step by step and roll your own implementation!. I have not used it yet but reading through the post gave me an idea that it should serve my purpose. I want to know if anyone has tried it and if it is advised to go for it?
I have one more question to ask; I have used Unity for DI and it is all cool but for AOP, unity is not a good option for my purpose hence I will definitely go for some other tool/library (maybe the one I suggested above!). Is it good to have Unity and something else for AOP in the same application, will there be any problem?
Can anyone please help me here? Thank you in advance!
I think you'll find few good options once you preclude PostSharp and also want to intercept static code.
Some options that you might check out are SheepAspect and Fody, which both take a similar approach to PostSharp (post-compile weaving). Both are very nice and show promise, but are relatively young compared to PostSharp.
I work in a small organization that has built an enterprise SaaS solution. Up until this point our workflows have had no programmatic interface. We're moving to a model that will allow for an end user to do anything programmatically that can be done in the UI. I'm looking for suggestions in terms of the language/framework that you would use to build that programmatic layer.
From an organizational perspective I would like the current UI team to also have ownership of the API. That team is familiar with PHP, Rails, and Javascript. Our current back-end code is written in Scala. I'm leaning toward not doing the APIs in Scala because it doesn't seem like the right tool for the job and the lack of subject matter expertise around it on the UI team.
From a functionality perspective most of the APIs will be fairly simple database operations (CRUD) with perhaps some simplistic business logic applied on top (search for example).
I'm a bit intrigued by using Node.js for this as everyone on the team is really strong with Javascript. That being said I don't just want to hop on the semi-new technology bandwagon. Because it is enterprise software, unit testing frameworks, reusability, and extendability are all important considerations as well.
Any suggestions?
I realize this question was about technology options, but there's a fundamental concern that seems really important to call out:
From an organizational perspective I would like the current UI team to also have ownership of the API.
While this sounds like a logical approach, it may not work out well unless you're UI team is made up of really solid engineers. SaaS API development is arguably one of the most challenging aspects of modern software design. A great API will make everyone's lives easier, while a poor API will bring your system to its knees and leave you completely clueless as to why.
As a quick example, if you don't solve the end user's needs in the right way, you're likely to force a number of n+1 problems on them (and thus, on you.)
There is a bunch of great material out there about how to design great APIs and even more about the pitfalls of designing a bad one. Generally speaking, most of the UI devs I've worked with, particularly ones that are only familiar with scripting languages, are not people I would entrust to API design. Instead I would utilize them as customers (in a Scrum sense) who guide the design by describing end-user needs.
I faced something like this on a previous project, where we ended up going with a combo of Esper and our own DSL written using ANTLR 3.0. Our biggest concern with using a fully funcional runtime, was sandboxing the user's code.
That said, I think Node.JS would be one of the easier ones to sandbox and it fits your needs. Maybe using something like this: http://gf3.github.com/sandbox/ or looking into Cloud9's code to see how they keep things safe. I also like that with Node.js you could give your users a pretty niffy editor using Ace.
Also check out this post: How to run user-submitted scripts securely in a node.js sandbox?
Lately I'm hearing much about COM at my work. I also learnt that COM is old. COM is deprecated. There is no future for COM. Are these true too?
I want to learn COM because I want to know what is the big fuss about it, but I'm unable to convince myself that this is a solid reason for spending so much time and learning it.
So, Can any one tell me:
Why should I learn COM?
Once I learn COM what can I do using it? I mean its applications.
I just don't see COM going away any time soon. If you want to be a windows expert, you must understand how it works.
Learning COM (or at least being au fait with its concepts) means you can integrate with thousands of existing components, including Microsoft Word and Excel.
I work largely in the Java domain, but having a little knowledge of COM means I can interface effectively to Word and Excel (in particular) to programatically create/read documents. I don't have an in depth knowledge, but I have a little, and having that increases my productivity substantially.
You should learn enough about COM to know that you don't want to learn any more.
The details of COM - particularly from a multithreaded or C++ application - are excruciatingly irritating, and I would not wish them on anyone (I don't know them myself, but I know enough to know this).
Therefore if you do need to call a COM library, you should learn enough COM to be able to do so, then stop. Ideally, use a language such as C# or Delphi where some (or hopefully most) of the details are handled for you relatively transparently.
There are a lot of COM libraries around, but if you feel you want to use one, you should look at its specific documentation for how to do this - it probably has a reasonable example that you can simply adapt for your own use without too much effort. If it does not, then it clearly isn't very good and shouldn't be used.
COM is definitely worth learning to at least some level if you are a Windows developer. Another common case for its use, in addition to the others already mentioned, is in the implementation of binary behaviors and BHOs for Internet Explorer. They are both implemented using COM interfaces between IE and your code.
I'd also like to recommend a couple of resources for learning about COM:
Don Box's Essential COM. It is an excellent description of why COM is the way it is and really helps you get a deeper understanding of what is going on. If you take the time to read this book, then you will have a fundamental understanding of COM internals that will serve you very well.
These two articles: { 1, 2 } ...are a very good discussion of the particular subject of COM apartments, alluded to as "excruciatingly irritating" (unfairly, imho) in MarkR's answer.
I work for a large state government agency that is a tad behind the times. Our skill sets are outdated and budgetary freezes prevent any training or hiring of new employees/consultants (firing people is also impossible). Designing business objects, implementing design patterns, establishing code libraries and services, unit testing, source control, etc. are all things that you will not find being done here. We are as much of a 0 on the Joel Test as you can possibly get. The good news is that we can only go up from here!
We develop desktop CRUD applications (in C++, C#, or Java) that hit the Oracle database directly through an ODBC connection. We basically have GUI's littered with SQL statements and patchwork code. We have been told to move towards a service-oriented n-tier architecture to prevent direct access to the database and remove the Oracle Client need on user machines.
Is WCF the path we should be headed down? We've done a few of the n-tier application walkthroughs (like this one) and they seem easy to implement, but we just don't know enough to understand if we are even considering the right technologies. Utilizing the .NET generated typed DataSets seems like a nice stopgap to save us month/years of work (as opposed to creating new business objects from the ground up for numerous projects). Is this canned approach viable for a first step?
I recently started using WCF services for my Data Layer in some web applications and I must say, it's frustrating at the beginning (the first week or so), but it is totally worth it once the code is deployed.
You should first try it out with a small existing app, or maybe a proof of concept to make sure it will fit your needs.
From the description of the environment you are in, I'm sure you'll realize the benefit almost immediately.
The last company I worked for chose WCF for almost the exact reason you describe above. There is lots of good documentation and books for WCF, its relatively easy to get working, and WCF supports a lot of configuration options.
There can be some headaches when you start trying to bend WCF to work in a way not specifically designed out of the box. These are generally configuration issues. But sites like this or IDesign can help you through those.
First of all, I would definitely not (sorry for the emphasis) worry about the time you'll save using typed DataSet's versus creating your own business objects. That is usually not where you will spend most of your development time. I prefer using business objects myself.
In you're situation I would want to implement a proof-of-concept first. One that addresses all issues you may encounter. This proof-of-concept should implement an entire use case, starting on the client, retrieving data from the database and returning it to the client. You should feel confident about your implementation before continuing.
Then about choice of technology. WCF is definitely a good choice for communication between your client applications and the service layer. I suppose that both your clients as well as your service layer will become C# applications? That makes things a lot easier since interoperability between different platforms (Java/C# for example) is still not trivial although it should work in most cases.
Take a look at Entity Framework (as there are a couple Oracle providers available for it already) in conjunction with .NET 3.5 SP1 which enables built-in WCF serialization of your EF generated classes.
Here is a good blog to get started: http://blogs.msdn.com/dsimmons
CSLA might be a good fit for your N-Tier desktop apps. It supports WCF, has a large dev community, and is well documented. It is very object oriented.