Related
I have been reading a little on Monocross and it seems to support a model very similar to ASP.NET MVC. It can use HTML5/CSS/Javascript as the UI.
Looking initially directly at MonoDroid and MonoTouch, it encourages the developers to develop with controls native to the device. Am I correct in saying the Monocross supports a HTML/CSS/Javascript with HTTP/GET/POST on all devices? MonoDroid/MonoTouch supports cross platform development all the way up to the UI, but this approach seems like I get theoretically get 100% (or near) code reuse. Is this correct?
MonoCross is a very thin layer on top of Xamarin's code. (See that Xamarin sticker in the top right corner?)
They offer to reuse the same MVC code across different implementations, such as MonoTouch and MonoDroid.
Abstracting away MVC works for small samples but these guys seem to religiously believe in 100% code sharing—something I don't subscribe to. It is a beautiful concept, but it never worked in the real life.
Making great apps is hard, but I don't think it's hard because database technologies differ, or because you have to write similar classes for ASP .NET MVC, MonoTouch or MonoDroid. If that was the real challenge with software development, we'd have solved it many years ago.
MonoCross seems to be an exercise in premature generalisation—something that all programmers love.
But abstraction isn't free. Consider this anecdote by Eric Gunnerson:
I've know teams where this snowballed - they ended up with a "swiss army knife" component that was used in a lot of different scenarios. And like many components that do a lot, it was big, complex, and had a lot of hard-to-understand behavior. But developing it was an interesting technical challenge for the developers involved (read that as "fun and good for their careers"...)
The problem came when the team found that one operation took about 4 times as long as it should. But because of the generalized nature of the component doing the operation, there was no easy way to optimize it.
If the operation had been developed from scratch without using the "uber-component", there would have been several easy optimization approaches to take. But none of those would work on the generalized component, because you couldn't just implement an optimization in one scenario - it would have to work for all scenarios. You couldn't afford the dev cost to make it work everywhere, and in this case, even if you could, it would cause performance to regress in other scenarios.
(Emphasis is mine.)
While MonoCross developers seem enthusiastic about it, there doesn't seem to be a community around the project, and I couldn't find a single app built on top of iFactr or MonoCross.
That being said, I don't think they offer anything valuable over MonoTouch or MonoDroid.
On a sidenote, Miguel approves :-).
I've got to convert a not terribly complicated bespoke project management system from MsAccess Application to PHP/MySQL. I've been programming for donkey's years but embarrassingly know practically nothing about modern methodologies.
So the old 'learning curve' versus 'improved efficiency' conundrum rears its ugly head once again.
Although I've Googled up some stuff I don't want to prejudice your suggestions, where would you start, I'm at your mercy?
What sort of learning curve am I looking at?
Consider learning a PHP framework and its philosophy and architecture to produce the application. You'll be glad you did.
http://www.phpframeworks.com/
Basically, this will help you get up and running quickly with all of the necessary moving parts, in a way that promotes best practices. IMO it's probably the quickest and best way to accomplish your goals.
For recommendations on which one to choose, have a look here:
https://stackoverflow.com/questions/184395/what-is-the-best-free-php-framework-working-on-shared-hosting-and-why
Well, when you say you been writing code for years, do you have any choice as to the final platform?
Access 2010 can create web based applications that scale horizontally in a HUGE way. The resulting applications don't requite Silverlight or even any ActiveX, but ONLY a standard browser. Here is a video of a application I wrote in Access, and note at the half way point I switch to running in a browser.
http://www.youtube.com/watch?v=AU4mH0jPntI
Access 2010 also now does have database triggers and stored procedures. However, you are hinting that you don't have a choice of technologies here so the above new features and even the new Web site creating ability of Access is thus moot for you.
I guess the 1st area I would start with is installing and setting up MySql. The MySql site has some good links to tutorials etc. You simply have to get up to speed with that database server and get conformable with it regardless of learning PHP anyway, so that one step and area I would start out with. And, if you worked with databases, then you find MySql quite easy to get up to speed with so you feel like you making some progress as you embark on this new road
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks
Since we are ambitiously aiming to be big, scalability is important, and so are globalization features. Since we are starting out without funding, price/performance and cost of licences/hardware is important. We definitely want to bring AJAX well present in the web interface. But apart from these, there's no further criteria I can come up with.
I'm most experienced with C#/ASP.net, PHP and Java, in that order, but don't turn down other languages (Ruby, Python, Scala, etc.).
How can we determine from the jungle of frameworks the one that suits best our goal?
What other questions should we be asking ourselves?
Reference material: articles, book recommendations, websites, etc.?
For me, the most important things to consider were:
Fantastic lead developers who I trust to keep working on the project.
Googling a question brings a lot of good answers.
Most importantly, I have to like the way the code flows.
Edit: Also they have to be anal about coding standards. If there is inconsistency, I get very annoyed.
Those 3 points brought me to Symfony. It is always using the latest cutting edge features of the latest PHP version. Symfony 2.0 is using namespaces before any other framework.
Two of your points were:
i18n - there is great support for it (helps that the company behind it is French, so i18n is a first class citizen).
Scales - Yahoo Answers and Vimeo use Symfony and contribute back code. If those guys can scale Symfony to 100 million users, you can too :)
It all depends on the type of project you will be developing.
Are you building a web application or a heavy content website or something else?
You also mix up programming languages with frameworks. The frameworks for PHP that I know are: CakePHP, CodeIgnitor, Zend and Symfony. For an out-of-the-box heavy content website I would suggest Drupal or Expression Engine.
It seems you won't be developing yourself. In that case I would determine the cost and availability of programmers and how widely the framework is supported and by who it is backed. The Zend framework is backed by the guys behind PHP, while CodeIgnitor is backed by the guys behind Expression Engine. Drupal has professional support packages,...
IMHO, for something that will have a lot of users, go for a compiled language.
If you don't try it, you will not know. So, I'd say do a small project in each of the frameworks you are seriously thinking about. I would prepare myself to do a lot of testing if it's something I'll be maintaining for some years. It's better to start off on the right foor than to get half way through a project only to realize you took the wrong path. There may be some requirements that end your search. For example, your servers' OS, a framework feature, or scalability. If you lay out your software plans and requirements, you probably will have very little left to choose from - unless your project really is quite generic or simple.
When a new version of a framework or language appears (e.g. .NET 3.5, SQL2008), what approach do people take to when to adopt/upgrade?
Generally developers will say as soon as possible (they want it on their CV and from a management perspective giving them what they want provides a motivation boost) but commercially there is often little incentive (few clients demand the latest version) and from a cost perspective (retest, training) there is often a disincentive.
I'm particularly thinking of "on-going" systems and projects (such as in a software house) which exist and evolve over years where taking the "new projects use the new technology" approach doesn't work.
Are people driven by specific requirements (the need to use a new feature, a potential or existing client demanding support for it), do they formally assess it (in which case what are the criteria) or do they upgrade as a matter of routine (in which case when - leading edge vs. bleeding edge)?
Do people think that not being on the latest version of something should be considered technical debt and managed as such?
Or is "if it ain't broke don't fix it" a valid approach?
Read up on Technical Debt. This is a simple cost-benefit decision.
The "if it ain't broke don't fix it" is a common management policy that says "tomorrow's dollars aren't worth as much as today's, so don't plan for future improvements." Eventually technical debt accumulates to the point where the product can no longer limp along.
The most common breaking point is when some piece of the infrastructure is no longer supported. By then, incremental change is impossible.
Reinventing from scratch is a new capital investment. Fixing existing code is an expense. The accounts force management to make technically crazy decisions.
In the case of open source software, it requires careful technical management since there's no official "support sunset" announcement from Oracle/Sun. Bad technical management, of course, leads to technical bankruptcy.
We look at the support lifecycle costs. For how long are the older versions supported, and at what costs? Platforms like Windows and Java tend to move fast as compared to mainframe environments, and part of the cost of doing business on those platforms is to perform periodic upgrades. In a rational world, that is!
New versions can have killer features we need -- but that is rare in enterprise development. The main positive selling points of new versions (as opposed to negative ones such as expired support) tends to be greater developer efficiency, which is hard to measure. Against that, as you indicate, the cost of retraining must be considered, not only for the initial developers, but, crucially, for maintenance. In each upgrade, some applications tend to be left behind as too critical to retire, and too expensive/fragile to upgrade. Over time, the number of platforms and versions you have to support increases overall technical debt (no matter their age).
Another criterion for upgrading to new versions (which you note) is the ability to attract and retain staff. With the current economic phase, that's playing second fiddle, but still cannot be ignored completely. You want to have at least a seasoning of enthusiastic and knowledgeable developers.
I think the killer question is whether your app will survive long term if you NEVER upgrade the platform/language version. If you think it can't, you may as well upgrade sooner rather than later, as it will only become harder.
Think about how long your app should be actively developed until you need a full rewrite. If you never plan to rewrite it, I would upgrade continually. Consider how difficult it will become to find the best developers if you are working in an outdated technology. Consider how new framework/language features could speed up your development process in the long term, for a bit of short term pain.
When you really need to. .NET 1.0 was crappy, 1.1 was a nice upgrade, but Web development with VS2003 was not so smooth. Things improved with VS2005 and .NET 2.0 – and I see still many developers and companies are stick to .NET 2.0. Previous versions were so fresh, version 2.0 was mature tech. So, if you were happy with 1.1, why would you upgrade? If you are happy now with 2.0, why upgrade to 3.5 or 4.0?
When the benefits of upgrading (more features, or a bugfix you need) outweigh the risks/costs involved (new issues, breaking existing code).
When you develop for Microsoft based platforms, like a Windows Forms App for Windows or ASP.NET webapp for Windows Server, the nice time to migrate is for every two major versions of OS.For example, if your app has been developed for Windows 2000, you ought to migrate to Vista though XP can be neglected. Similarly, if it were designed for XP SP2, you can safely ignore Vista and target Win 7. Usually Microsoft never breaks (or rarely breaks) incremental OS updates. So an app running on today's OS will definitely run on the next. But never on the one following it. (It if runs how can M$ make money???)
Source: Self... Windows Developer for over 5 yrs)
I'm in the upgrade as soon as possible camp (though I might wait a month after a new version come out just in case for uncaught issues). There are a few things you need to think about:
1. Security Releases
Many of the people who tell me if it isn't broke don't fix it are also the same people who would close their 2 eyes when security patches get released. Think Equifax.
To me it is an ethical responsibility to at least be on security supported versions of a framework. We owe it to our customers to safeguard their data.
2. Attracting & Retaining Talents
There are lots of talk about how the programming language or framework used doesn't matter. But in my experience, the cleanest code and design for a web app are usually written by the people who are passionate about the framework & programming language used because of their experience & expertise with it.
These people are unlikely to stay around for long or join your company if you stick to a very old version. Please think about your developers' happiness.
3. Newer, simpler ways offered by the newer version
Very often newer versions of a framework make something hard in the past much easier. If we do not upgrade, we miss out on the good new packages/features and we write our code in the old frustrating way knowing there is a much simpler way to achieve the same feature. And when it comes time to upgrade, we may end up having to change again to the new way. So why not upgrade and use the new better way and waste less time?
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
In evaluating different systems integration strategies, I've come across some words of encouragement, but also some words of frustration over BizTalk Server.
What are some pros and cons to using BizTalk Server (both from a developer standpoint and a business user), and should companies also consider open source alternatives? What viable alternatives are out there?
EDIT: Jitterbit seems like an interesting choice. Open Source and seems to be nicely engineered. Anyone on here have any experience working with it?
BizTalk Server's key benefit is that it provides a lot of 'plumbing' around deployment, management, performance, and scalability. Through Visual Studio, it also provides a comprehensive framework for developing solutions, often with relatively little code.
The frustration and steep learning curve that others mention often comes from using BizTalk for the wrong purpose and from a misunderstanding about how to work with BizTalk and message-oriented systems in general. The learning curve is not as steep as most people suggest - the essential part of the underlying learning actually focuses on changing thinking from a procedural approach to a stateless message-based approach.
A drawback people often cite is cost. The sticker price can seem to be quite high; however, this is cheap in comparison to the amount you'd spend on developing and supporting features on your own.
Before you consider alternatives, or even consider BizTalk server, you should consider your organization's approach to integration and it's long term goals. BizTalk Server is great in cases where you want to integrate systems using a hub and spoke model where BizTalk orchestrates the activities of many applications.
There are other integration models too - one of the more popular ones is a distributed bus (don't confuse this with the term "Enterprise Service Bus" or ESB). You can also get BizTalk to work as a distributed bus and there are alternative solutions that provide more direct support. One of the alternate solutions is an open source solution called nServiceBus.
When considering whether to use a commercial product like BizTalk, verses something else (open source or developed in house), also consider maintenance and enhancements and the availability of the necessary skill-set in the marketplace.
I wrote some articles that go into more detail about the points I discussed here - here are the links:
Why BizTalk?
Top 10 BizTalk Mistakes
Extensibility Features in BizTalk Server
Open Source Integration with nServiceBus
My experience with BizTalk was basically a frustrating waste of time.
There are so many edge cases and weird little business logic tweaks you have to make when you are doing B2B data integration (which is probably the hardest part of any enterprise application) that you just need to roll your own solution.
How hard is it to parse data files and convert them to a different format? Not that hard. Unless you're trying to inject a bloated middleware system like Biztalk into the middle of it.
As a BizTalk consultant I have to agree at least partly with Eric Z Beard, there are a lot of edge cases that take up alot of time. But quite a few scenarios are handled extremly smooth as well, so it all depends IMO. But when you (Eric) call BizTalk bloated I have to disagree! We've found that the performance and reliability is excellent, it's flexible and comes with a lot of good adapters out of the box.
BizTalk needs to be used correctly,
I am a BizTalk developer and my experience with BizTalk is quite good.
Its reliable, performant, scalable, contains a lot of built in architectural patterns and build in components to make integration easy and fast, you get security, retries, secondary transports, validation, transformation etc... and what ever you dont have build in with BizTalk you can easily customized with .NET code, its basically a hard earned integration system and you get all this in one box.
BUT you need to know how to implement BizTalk correctly, not once I came across solutions that where implemented and often also architected incorrectly.
but the real benefit of BizTalk is that you can implement small solutions and scale up whilst most other integration systems from big vendors will only sell a whole integration pack which can cost much more.
BizTalk is considered the most complicated server from the house of Microsoft.
So any body saying BizTalk is not good dosent know BizTalk period.
We evaluated BizTalk at our company and were really disappointed.
We are using IBM WebSphere Transformation Extender (which has lots of (other) problems, too) and the mapping tool of BizTalk is a joke in comparison to WTX.
The graphical tool is not really usable for complex mappings (we have schemas with a few hundred fields in repeating groups) and if you do more than the usual "concat first name and last name to name" mappings, you will be tired of the graphical approach (for example the arguments of the functoids in the graphical mapper are not labeled and the order in which you connect fields to these arguments is important).
The XSLT-Mapper was usable but not really convincing, and even the microsoft rep told us to use a tool like XMLSpy for XSLT and load the resulting XSL file into BizTalk.
A third approach to mapping is to use C#-Code for the mapping, which was not acceptable for us as a general approach (we don't want to teach everyone C#).
In addition to the mapping tool we did not like the deployment in BizTalk. In order to deploy your process, you need to make lots of settings in different tools and places. We had hoped to find a mechanism like a WAR file for Java Web Applications in BizTalk, so that you can give one archive for your whole process solution to your administrator and he can deploy it.
We've been using BizTalk since version 2004, and now have a mix of versions 2006 R2 and 2004 running. I found that the learning curve was quite severe, and development time for solutions is not always quick. Those are definitely shortcomings. Where BizTalk really excels is in its fault tolerance, gauranteed delivery, and performance. You can rest assured that data will not get lost. Retry functionality and fault tolerance robustness is baked in so generally speaking if systems are down BizTalk will handle that and successful delivery will occur once systems come back on line. All these issues such as downtime, etc that are important in an integration scenario are handled by BizTalk.
Further, generally speaking when developing solutions BizTalk abstracts the communication protocols and data formats of the native systems by dealing with everything as xml, so when developing solutions, you typically don't have to wrote code specific to those systems, you use the BizTalk xml framework.
In the last year, we've implemented a java open source engine called Mirth for our HL7 routing. I found that for HL7 purposes, the HL7 adaptor for BizTalk is a challange to work with. Management dicated that we use Mirth for HL7 routing. Where BizTalk falls down in terms of learning curve, Mirth makes up. It is far easier to develop a solution. The problem with mirth is that it doesn't really have any gauranteed delivery. Most of the adaptors (except for hl7) have no retry functionality so if you wanted that you'd have to write your own. Second, Mirth can lose date if it goes down. I would call it very easy to use (although there is no documentation) but I'd be hard pressed to call it an enterprise solution. I'm going to check out jitterbit which was mentioned by someone else.
We used BizTalk for a couple of years, but gave it up for our own custom framework that allowed more flexibility.
There is always Sun's (now Oracle) OpenESB framework. Its generally speaking a smaller, lighter version of Biztalk but with roughly all the same features.
You do get to write more code with it, though.
Its Open Source as well.
In the OSS space (though I've never used them as a BizTalk replacement personally - this is anecdotal) you can use one of the Java/J2EE Messaging engines such as OpenMQ (which is the Sun enterprise one rebadged and without support). If you need Orchestration / Choreography (i.e. SOA/ESB pieces) on top of this, you could look into something like Apache Mule
My experience with BizTalk and doing B2B integrations is that most organizations do not truly do schema first design or fully understand xml standards for that matter. Most tend to weave objects and hope they materialize into meaninful schemas. In an enterprise environment, this is backwards.
BizTalk does have a learning curve, but once you get it you are rewarded with durability, performance, true scalability, and extensibility. Like most have said though, it best to make sure it meets your needs and contort your needs to BizTalk.
In the past I have worked with BizTalk 2004 through 2009, and another product called webMethods.
I have no direct experience with JitterBit, but I have heard very good things from coworkers.
I came across Apatar (unable to post url, but Google finds it) while looking for a solution cheaper than BizTalk. I have yet to try this out.
My last company had many problems with BizTalk being too complex and ridged, but I can’t help but think this was mainly down to the implementation the consultant did.